There are two ways to fix this:
(1) Change the spec to define that (is == function) returns the non-variadic parameters.
(2) Create a '...' object inside the compiler, and allow it to be a member of a tuple. Variadics are neither types nor expressions, nor symbols. Creates lots of special cases all through the compiler.There are tricky examples like:
template baa(T...) {
alias void function(T) a; // OK, params are (char, ...)
alias void function(T, ...) b; // illegal: (char, ..., ...)
alias void function(T, int) c; // illegal: (char, ..., int)
}
alias baa!( is ( void function(char, ...) == function)).b baz;
And if we fix those problems, maybe we should allow this syntax:
alias baa!(char, ...).a foo;
because otherwise I don't know what to print when you do:
pragma(msg, T);
but then we have to make sure we can always distinguish variadic function parameters from template variadics.
Is this issue important enough to justify (2) ?
Comment #5 by smjg — 2011-12-17T18:27:18Z
(3) Have function(char, ...) just not matching function(T) for any value of T. ... is a fundamentally different kind of thing from a type, so it doesn't seem to make sense to allow it as an element of a type tuple.
Comment #6 by clugdbug — 2011-12-19T04:59:44Z
(In reply to comment #5)
> (3) Have function(char, ...) just not matching function(T) for any value of T.
> ... is a fundamentally different kind of thing from a type, so it doesn't seem
> to make sense to allow it as an element of a type tuple.
How does that solve the problem? The root cause is that is( ==function) assumes that all of the function parameters can be returned in a tuple, but that isn't true for ...
Or do you mean that is( x==function) should be an error if x has a variadic parameter?
Comment #7 by smjg — 2011-12-19T05:23:40Z
(In reply to comment #6)
> How does that solve the problem? The root cause is that is( ==function) assumes
> that all of the function parameters can be returned in a tuple, but that isn't
> true for ...
In what way does it make that assumption?
> Or do you mean that is( x==function) should be an error if x has a variadic
> parameter?
Of course not. What would be the point of that?
Comment #8 by clugdbug — 2011-12-19T22:34:00Z
(In reply to comment #7)
> (In reply to comment #6)
> > How does that solve the problem? The root cause is that is( ==function) assumes
> > that all of the function parameters can be returned in a tuple, but that isn't
> > true for ...
>
> In what way does it make that assumption?
It declares T as a tuple containing all of the function arguments.
Comment #9 by clugdbug — 2011-12-19T22:44:37Z
(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #6)
> > > How does that solve the problem? The root cause is that is( ==function) assumes
> > > that all of the function parameters can be returned in a tuple, but that isn't
> > > true for ...
> >
> > In what way does it make that assumption?
>
> It declares T as a tuple containing all of the function arguments.
Complete section of the spec:
------
6. is ( Type Identifier == TypeSpecialization )
The condition is satisfied if Type is semantically correct and is the same as TypeSpecialization. The Identifier is declared to be either an alias of the TypeSpecialization or, if TypeSpecialization is dependent on Identifier, the deduced type.
If TypeSpecialization is one of typedef struct union class interface enum function delegate then the condition is satisifed if Type is one of those. Furthermore, Identifier is set to be an alias of the type:
keyword alias type for Identifier
function TypeTuple of the function parameter types
------
This is impossible if the function has a C-style variadic parameter. Although solution (2) would allow it to be a Tuple, it wouldnt be a TypeTuple. So a change to the spec is inevitable.
Comment #10 by smjg — 2011-12-20T03:54:21Z
(In reply to comment #9)
> Complete section of the spec:
> ------
> 6. is ( Type Identifier == TypeSpecialization )
You were suggesting in comment 6 that is(x == function), not is(x T == function), should fail if x is variadic.
> keyword alias type for Identifier
> function TypeTuple of the function parameter types
> ------
> This is impossible if the function has a C-style variadic parameter. Although
> solution (2) would allow it to be a Tuple, it wouldnt be a TypeTuple. So a
> change to the spec is inevitable.
I see now. So I suppose what we need is distinct syntaxes for extracting variadic and non-variadic parameter lists. So maybe:
is ( Type == function )
passes iff Type is a function type, variadic or not
is ( Type Identifier == function )
passes iff Identifier is a non-variadic function type, and
binds Identifier to a tuple of the parameter types
is ( Type Identifier , ... == function )
passes iff Identifier is a variadic function type, and binds
Identifier to a tuple of the fixed parameter types
Comment #11 by clugdbug — 2011-12-20T05:22:56Z
(In reply to comment #10)
> (In reply to comment #9)
> > Complete section of the spec:
> > ------
> > 6. is ( Type Identifier == TypeSpecialization )
>
> You were suggesting in comment 6 that is(x == function), not is(x T ==
> function), should fail if x is variadic.
I didn't intend to. All discussion has been about is(Type Identifier == function). Sorry that that wasn't clear.
> > keyword alias type for Identifier
> > function TypeTuple of the function parameter types
> > ------
> > This is impossible if the function has a C-style variadic parameter. Although
> > solution (2) would allow it to be a Tuple, it wouldnt be a TypeTuple. So a
> > change to the spec is inevitable.
>
> I see now. So I suppose what we need is distinct syntaxes for extracting
> variadic and non-variadic parameter lists. So maybe:
>
> is ( Type == function )
> passes iff Type is a function type, variadic or not
> is ( Type Identifier == function )
> passes iff Identifier is a non-variadic function type, and
> binds Identifier to a tuple of the parameter types
> is ( Type Identifier , ... == function )
> passes iff Identifier is a variadic function type, and binds
> Identifier to a tuple of the fixed parameter types
Yeah, that would work. But it's far more complicated than (1), changing one line of the spec to match the compiler, namely that:
is(Type Identifier == function) binds Identifier to:
-TypeTuple of the function parameter types
+TypeTuple of the function parameter types. For C-style variadic functions, only the non-variadic parameters are included.
and then (possibly*) provide some other mechanism for identifying if a function is C-style variadic. is() expressions are just about the ugliest thing in the language already, I'm loathe to recommend making them even uglier.
* I say possibly, because I think that given a tuple T and return type R, you can check if typeof(f) == extern(C) R function (T, ...)
So I'm not sure that any compiler changes are required.
Comment #12 by smjg — 2011-12-20T06:00:39Z
(In reply to comment #11)
> and then (possibly*) provide some other mechanism for identifying
> if a function is C-style variadic. is() expressions are just about
> the ugliest thing in the language already, I'm loathe to recommend
> making them even uglier.
Why only C-style variadics? D-style variadics with typeinfo just as well need to be considered. Of course, with typesafe variadics we can feasibly just keep the type and just discard the ... ....
Comment #13 by clugdbug — 2011-12-20T06:42:22Z
(In reply to comment #12)
> (In reply to comment #11)
> > and then (possibly*) provide some other mechanism for identifying
> > if a function is C-style variadic. is() expressions are just about
> > the ugliest thing in the language already, I'm loathe to recommend
> > making them even uglier.
>
> Why only C-style variadics? D-style variadics with typeinfo just as well need
> to be considered. Of course, with typesafe variadics we can feasibly just keep
> the type and just discard the ... ....
You're right. Fortunately, I don't think it's any different.
-TypeTuple of the function parameter types
+TypeTuple of the function parameter types. For C- and D-style variadic functions,
only the non-variadic parameters are included. For typesafe variadic functions, the ... is ignored.
Can you improve on that?
Comment #14 by github-bugzilla — 2012-01-21T11:24:41Z