refined sugar (was DMD 0.165 release)

Pragma ericanderton at yahoo.removeme.com
Tue Aug 22 10:04:32 PDT 2006


kris wrote:
> 
> # somefunk ({++i});
> #
> # rather than
> #
> # somefunk ({return ++i;});
> 
> Quite a difference, and both are still explicit rather than introducing 
> ambiguity. Or, use some kind of operator instead, like c# does?
> 
> # somefunk (=> ++i);
> 

Here's my $0.02.  I just noticed this:

import std.stdio;


void foobar(char[] x){
	writefln("x is a string: '%s'",x);
}

void foobar(char[] delegate() x){
	writefln("x is a delegate: '%s'",x());
}


void main(){
	foobar("value");
	foobar(cast(char[] delegate())("value")); //<=== note the cast()
}

... which outputs:

x is a string: 'value'
x is a delegate: 'value'

I was quite happy to find that this is a valid workaround, and that the 
result of the cast() isn't automatically resolved to the first variant 
of foobar().

As Kris has mentioned, having some way to cast an expression to a 
delegate /explicitly/ while still using some kind of shorthand would 
really help seal the deal here.  After all, cast() is really only used 
to circumvent implicit casting and to resolve type matching ambiguities 
- both of which are present in the current implicit expr-to-delegate 
conversion scheme.  I also feel that such an addition can quite happily 
co-exist with the current feature-set we have.

I'm not too crazy about '=>' but something like using {} without an 
embedded return (as others have mentioned) might be the right trick.  As 
long as it has the same behavior as the explicit cast() above, it has my 
vote.

foobar("value");
foobar({"value"});

It's subtle, yet impossible to confuse for anything else.

The only remaining problem is that casting a delegate in the /other 
direction/ fails

void main(){
	foobar({ return cast(char[])"value"; });
	foobar(cast(char[]){ return cast(char[])"value"; });
}

test.d(18): function test.foobar called with argument types:
         (char[])
matches both:
         test5.foobar(char[])
and:
         test5.foobar(char[] delegate())

I would expect cast() to disable the implicit expression/delegate 
conversion, as my first example seems to do this already.  Instead it 
allows a match for the delegate version of foobar() which is the same as 
saying "its okay to implicitly convert me back to a delegate" even 
though it was explicitly converted to something else.

I'm sure there's some kind of happy medium to be found between explicit 
and implicit conversions when finding a match for a given contract. 
However, I don't think we're there yet.

-- 
- EricAnderton at yahoo



More information about the Digitalmars-d-announce mailing list