Re: [boost] Re: Fun, only handled by vc6/7!

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2003-01-13 01:48:24

>From: "Gennaro Prota" <gennaro_prota_at_[hidden]>

> On Sun, 12 Jan 2003 22:38:06 +0100, Terje Slettebø
> <tslettebo_at_[hidden]> wrote:
>
> >>From: "Paul Mensonides" <pmenso57_at_[hidden]>
> >> In other words, the "void" parameter list is fundamentally different
than
> >> "type void".
> >
> >It appears this is right. 8.3.5/2 says: "[...] If the
> >parameter-declaration-clause is empty, the function takes no arguments.
The
> >parameter list (void) is equivalent to the empty parameter list.
>
> Ok. But the point is not whether it is equivalent to the empty
> parameter list or not but whether it is legal to have a type-id (of
> type void) instead of the keyword 'void'.

That was the point I was trying to make, in the part of my posting you quote
below here. That this section of the standard may be interpreted as that it
accepts the text "void", but not a type expression that evaluates to void,
like I said. That's why I used quotes in the posting, to emphasise that the
standard may require the literal text, rather than a type expression.

> By grammar that's already
> allowed, but of course this is not enough. Personally I don't think
> the standard is clear about this, though the response to DR18 says so:
>
>   http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_closed.html#18

The NAD you refer to shows that the way I interpreted the standard, is the
way it was intended.

> In some old newsgroup post, searched through Google a while ago, I
> also read that the committee rejected a proposal to allow the
> generalized form f(T) with T=void, but I've never read the proposal
> itself (I didn't find it at that time). Maybe Dave can do something to
> raise the dead though ;-)

Why would we want that? What is this useful for?

> >Except for
> >this special case, void shall not be a parameter type (though types
derived
> >from void, such as void*, can)."
>
> Er... don't remind me this sentence. It seems to say that in
>
>     f(void);
>
> void is a parameter type :-(

No, I don't think so. The previous sentence says: "The parameter list (void)
is equivalent to the empty parameter list." Then it follows with what is the
rule, except for this special case. IOW, it's not a parameter type in the
special case, and it's not otherwise, either.

You could understand it the way you indicate, but the NAD shows that's not
the intention.

> But then, such a parameter would be an inexistent local
> variable of incomplete and incompletable type, not something that one
> would desire, from a logical perspective, either ;-)

Exactly. Which is why it's forbidden.

> Fortunately it's
> not necessary to go into such logical and linguistic contortions to
> clarify the situation in one direction or the other.

How would you propose to clarify it?

>From your next posting:

>>In some old newsgroup post, searched through Google a while ago, I
>>also read that the committee rejected a proposal to allow the
>>generalized form f(T) with T=void
>
>Maybe it's worth noting, as well, that then generalizing things a bit
>something like:
>
>
>  template <typename T1, typename T2, typename T3>
>  int f(T1 t1, T2 t2, T3 t3);
>
>
>becomes a generator of variadic functions with a fixed maximum number
>of arguments.

Really? How would you impleent that? Should the following:

int result=f();

mean that it gets instantiated with f<void,void,void>? In that case, how
will you deal with the "variables" t1, t2, t3, now "variables" of type void?
That's not allowed. As you say in the following posting, that would only
possibly work if you avoid the variable names. However, how will you then
use the function, in the general case? Perhaps a specialisation?

template<>
int f(void,void,void);

Hm. We also have the issue that with this scheme, no arguments passed would
be interpreted as objects of type void passed, for the purpose of overload
resolution. As if overload resolution isn't complex enough as it is. :)

Regards,

Terje