refined sugar (was DMD 0.165 release)

[Lutger]

Pragma wrote:
> 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.
> 

Changing the first foobar to this doesn't work however:
foobar("some" ~ "value");
// or:
foobar("value: " ~ aFooBarMessage.toString())