Prefer { } syntax? - was Re: Lazy eval

[Chris Miller]

On Mon, 21 Aug 2006 22:41:24 -0400, Walter Bright  
<newshound at digitalmars.com> wrote:

> Derek Parnell wrote:
>> On Mon, 21 Aug 2006 16:33:00 -0700, Walter Bright wrote:
>>> The problem with requiring the { } around the argument is that  
>>> programmers just don't like it. I don't think I can make them like it.
>>  Huh? You asked them all? You didn't ask me and I like it.
>
> Did you use it before 0.165? Did anyone? Everyone I'd show the { }  
> syntax to reacted with zzzzzz. I show them the one without, and all of a  
> sudden they are excited about it and can think of all kinds of uses.

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.

The previously noted foo(bar++) doesn't say how many times bar is  
incremented, if at all. 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.