Subject: Re: [sv-cc] DirectC: passing by name, restrictions
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Mon Feb 24 2003 - 14:44:11 PST
> > I would recommend more stringent restrictions.
> > [...]
> > b) arguments may be passed by name only for the external functions that have
> > all their formal arguments named
>
> > c) if multiple external declarations specify the name of a formal argument,
> > than the names must be the same.
> > In other words, a name is still optional, but if specified, it becomes
> > a part of definition. Repeated declarations must either use the same name
> > or not specify the name.
Michael wrote:
> From what I see the only difference is on b) You require that
> there is always a name.
> I propose that we require either a name for an argument OR a default value.
So, you would allow a mix: part of parameters have names, part of parameters
have default values (some may have both a name and a default value).
Something like in the following 4 versions of external declaration?
extern void foo(int); // the simplest case
extern void foo(int i); // optional name
extern void foo(int i = 1); // optional name AND a default value
extern void foo(int = 1); // only a default value ????
The last case looks weird ...
I don't require that "there is always a name"; I require this only for
a function for which the passing by name is to be used.
Shortly, I require that naming is consistent and all parameters must be named
in order to allow passing by name for a given function.
Please note that the above requirements are met by the native SV functions!
All formal parameters are named and names are consistent (since there is no way
to re-name the formals).
Michael wrote:
> on c) You require that all names for a formal argument match or are left
> unspecified [although think this collides with your rule in b)]
No, there is no collision or contradiction. b) is required only for functions
for which the passing by name is used. If this feature is not used for
a specific function, that the names of formal arguments are optional for that
functions, yet must be consistent in multiple declarations.
Michael wrote:
> I have to admit I didn't think about conflicting names as you defined within
> your example. I still believe that with the restrictions I stated already
> PLUS forbidding to use the same name for different formal
> parameters, it would be possible to solve this issue. So
> extern void foo(int count = 13, bit status = 1);
> extern void foo(int i = 13, bit status = 1); // different names
> is correct and can always be properly solved:
> foo(status = 0, count = 4); // O.K.
> foo(status = 0); // ambigous, but the default value is the same.
> It is still the _same_ Direct C function!
> foo(count = 1); // O.K.
> foo(i =2); // O.K.
> foo(); // ambigous, but see above.
Consider the two calls from your example: foo(count = 1); foo(i = 1);
One may think that they assign 1 to different formal argument (and use default
values for the remaining arguments). Actually both names refer to the same
argument. Isn't it a bit confusing? What do we gain by that kind of ambiguity?
Then, what do you mean by "forbidding to use the same name for different formal
parameters"? The same name within a single declaration? Within a family of all
declarations of a function?
IMO all multiple declarations of the same functions shall carry the same
relevant information, so any of the multiple declarations could be chosen
both by the user and by the compiler to guide them.
Optional formal argument names are irrelevant for passing by position and are
relevant for passing by name.
Unfortunately, we seem to have two conflicting guidelines:
- formal argument names in prototypes are optional and meaningless,
may be generally ignored for the sake of convenience
- names of formal arguments shall be unique and consistent,
in order to avoid confusion
I'm not happy with either solution.
Regards,
Andrzej
This archive was generated by hypermail 2b28 : Mon Feb 24 2003 - 14:51:19 PST