[Issue 7135] [tdpl] Multiple delegate-related issues (literal syntax, @system deduction)

d-bugmail at puremagic.com d-bugmail at puremagic.com
Sat Dec 31 03:13:21 PST 2011


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


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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug at yahoo.com.au


--- Comment #4 from Don <clugdbug at yahoo.com.au> 2011-12-31 03:12:50 PST ---
(In reply to comment #3)
> (In reply to comment #2)
> > I think (and perhaps I'm wrong) that the signature with ... and the one without
> > must be equivalent. The ... makes a difference only in the call syntax, but in
> > fact still passes an array. (Note that the variadics ending with "T[] param..."
> > are not unsafe C-style variadics.) Please advise - thanks!
> 
> Hmm, current compiler always raise an error against the difference of variadic
> argument kind (non-variarics vs typesafe-variadics vs C-style variadics).
> 
> But, from http://d-programming-language.org/abi.html
> 
> > The variadic part is converted to a dynamic array and the rest is the same as for non-variadic functions.
> 
> So, in ABI layer, (..., T[]) and (..., T[]...) might be same...

I don't think so. One difference is visible in declaration.html (there may be
other). It says:

"An implementation may construct the object or array instance on the stack.
Therefore, it is an error to refer to that instance after the variadic function
has returned:

int[] test(int[] a ...) {
  return a;       // error, array contents invalid after return
}
"
So, it would be legal to call the delegate with the Variant[]... stored on the
stack. But it would fail.
It might be OK to assign a (Variant[]...) function to a (Variant[]) delegate,
but I'm pretty sure the other direction doesn't work.

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


More information about the Digitalmars-d-bugs mailing list