Prefer { } syntax? - was Re: Lazy eval

[Walter Bright]

Chris Miller wrote:
> I very much like the { } syntax, it was just surprising to me.
> 
> The first piece of code I attempted to compile after installing DMD 
> v0.165 choked on this new no-brace feature.
> 
> tabs.d(120): function dfl.application.Application.run called with 
> argument types:
>         (MainForm)
> matches both:
>         dfl.application.Application.run(void delegate())
> and:
>         dfl.application.Application.run(Form)
> 
> MainForm is derived from Form; it doesn't exactly match with Form so 
> implicit matching rules kick in. Somehow MainForm turned into a delegate 
> returning void, which even seems like 2 levels of implicit matching, 
> when Form is obviously the best match.

A cast of a value to:
	void delegate()
is a match with conversions, as is a conversion of a derived class to a 
base class. Hence the ambiguity error.

> The previously noted foo(bar++) doesn't say how many times bar is 
> incremented, if at all.

It's once if foo's parameter is not a delegate. If it is a delegate, it 
is defined by the person who implemented foo().

> Perhaps there could be a compromise in syntax: 
> require { } but if there's just one expression in it, it can become the 
> return value and type:  foo({bar++});  I'm not sure if a semicolon after 
> the expression would be needed or cause problems.
> 
> 
> Back on function parameter matching rules, not having more than 2 levels 
> of matching rules (exact / implicit across the board) sucks in many 
> cases. It very much hinders the programmer when I don't think it even 
> needs the complexity of C++'s matching rules to be improved. As long as 
> there is a well-defined set of rules, it should be fine to have a few 
> levels of matching rules.
> 
> Examples:
>    * A derived class should match moreso with its base class.
>    * When one argument doesn't match exactly, the rest of the arguments 
> shouldn't automatically kick into implicit mode too.
> 
> I'm sure there are more; I've had to have a bunch of workarounds along 
> the way and forgot about them. If interested, I'll try harder to find them.

I admit there's a strong temptation to add more levels. But I don't 
think it's so clear which matches are obviously "better", and the more 
levels there are the more interactions there are, especially when 
multiple arguments are in play. With the current 2 level system, it can 
be frustrating, but it may in the end be beneficial by forcing one to be 
clear about which function will get called.