http://d.puremagic.com/issues/show_bug.cgi?id=664


Don <clugdbug@yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |spec


--- Comment #9 from Don <clugdbug@yahoo.com.au> 2011-12-19 22:44:37 PST ---
(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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=664



--- Comment #10 from Stewart Gordon <smjg@iname.com> 2011-12-20 03:54:21 PST ---
(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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=664



--- Comment #11 from Don <clugdbug@yahoo.com.au> 2011-12-20 05:22:56 PST ---
(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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=664



--- Comment #12 from Stewart Gordon <smjg@iname.com> 2011-12-20 06:00:39 PST ---
(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 ... ....

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=664



--- Comment #13 from Don <clugdbug@yahoo.com.au> 2011-12-20 06:42:22 PST ---
(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?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=664



--- Comment #14 from github-bugzilla@puremagic.com 2012-01-21 11:24:41 PST ---
Commit pushed to https://github.com/D-Programming-Language/d-programming-language.org

https://github.com/D-Programming-Language/d-programming-language.org/commit/e3ff6bd4a8c6d368a64d6a81af565868f6067c74 fix Issue 664 - is(func T == function) ignores variadic arguments

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=664


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------