doubly-lazy variadics?

Stewart Gordon smjg_1998 at yahoo.com
Tue Sep 5 16:08:29 PDT 2006


Bruno Medeiros wrote:
> Walter Bright wrote:
>> Don Clugston wrote:
>>> I noticed that DMD 0.166 accepts
>>>
>>> void func(lazy int delegate()[] ...)
<snip>
> Hum, that's odd, I was expecting that the "int delegate()" part would be 
> lazy, not the "int delegate()[]" .
> Such that an "func(lazy int[] ...)" would do what currently is done with 
> this special-case:

I've always understood that '...' merely adds syntactic sugar on the 
caller side, and never changes the semantics of the parameter 
declaration.  Therefore, the semantics would be the same as

     void func(lazy int[])

so that the int[], not the int, is lazy.  As such, the caller can pass 
in an expression that evaluates to an array, and this whole expression 
will be evaluated as one on the callee side.  When you change it to

     void func(lazy int[] ...)

these semantics would be preserved.  Of course, if the caller passes in 
separate arguments, then evaluation of the arguments would be on an 
all-or-nothing basis.  Basically,

     void func(lazy int[] ...);

     func(69 + qwert, yuiop * 105);

would become this internally:

     void func(int[] delegate());

     func(new delegate int[]() {
         return int[]![69 + qwert, yuiop * 105];
     });

borrowing the notation for array literals that's been recently proposed.

> function.html:
> "If the variadic parameter is an array of delegates with no parameters.
>   void foo(int delegate()[] dgs ...);
> Then each of the arguments whose type does not match that of the 
> delegate is converted to a delegate"
> This special-case, besides being a bit inconsistent(it's a special case! 
> :p ), may also be a bit error prone, such as when a given non-delegate 
> argument is converted to a delegate under those rules, but an error 
> should have occurred instead (because the programmer made an error of 
> calling).
<snip>

Depends on what is meant by "converted to a delegate".  If it's talking 
about the feature that existed only in 0.165 whereby expressions could 
be converted to delegates, then it's out of date.  If OTOH, there's some 
other type that can be implicitly converted to a delegate (I can't think 
of any OTTOMH), _then_ it would make sense (but also be redundant with 
the normal D matching rules).

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-@ C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- 
PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.



More information about the Digitalmars-d mailing list