refined sugar (was DMD 0.165 release)

[kris]

Walter Bright wrote:
> kris wrote:
> 
>> Walter Bright wrote:
>>
>>> I was going to call this 1.0 RC1, but I just could not resist adding 
>>> the lazy expression evaluation. This adds one of the big capabilities 
>>> of common lisp.
>>>
>>> http://www.digitalmars.com/d/changelog.html
>>
>>
>>
>> We could already do "lazy expression eval" in D, using dmd164 
>> delegates; sans new sugar. So that Lisp ability was already present?
> 
> 
> Yes. But few to nobody noticed it, and I'll posit that this bit of sugar 
> will expand its use by a couple orders of magnitude.
> 
> 
>> I like a bit of sugar as much as anyone, especially when it's part of 
>> some classy dark-chocolate. But there's some practical issues with 
>> this most recent syntactic sugar. The overload issue is a real one, 
>> and the added complexity of having to manually check a callee 
>> declaration before you can grok what happens to an expression arg will 
>> also become a realisitic problem. Particularly so when you happen to 
>> miss a method overload in some subclass somewhere.
> 
> 
> D (and other languages) already have that with in, out, inout, implicit 
> conversions, all the proposals for const, mutable, and other storage 
> classes. C++ has it for reference types, const types, implicit 
> conversions, etc. You already cannot tell what is happening with the 
> arguments without looking at the prototype.
> 
> I'll also point out that C/C++ programs routinely use macros to do the 
> equivalent (and much worse).
> 
> 
>> In this specific case, I suspect there needs to be an indication of 
>> some kind, at the call site, to clearly and unambiguously communicate 
>> to a person (and to the compiler) exactly what is going on.
> 
> 
> There already was (and is) in the form of { return exp; }. It's just not 
> accepted - I can hardly count all the comments I get from people saying 
> D didn't support this capability, and when I point out the { return exp; 
> }, they frown like people do when you tell them broccoli is good for them.


Yes; would be nice to eliminate the return and the secondary ';' so it 
looks like

# 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);


> 
>> Otherwise, this may be just the kind of sugar that rots the teeth of D ?
> 
> 
> Maybe, but I haven't seen any food stores carry the Odwalla vegetable 
> juice for years <g>.
> 
> I do understand your concern, and I think I understand the issues. Only 
> time and experience will tell us definitively if this is the right move 
> or not, but my gut tells me it is. I *do* know that this has a "gee 
> whiz" aspect to it that gets peoples' attention, and that's good for D 
> to help it develop its own clear place in the panopoly of programming 
> languages.


Perhaps ;)

I should point out that any and all of that "Gee Whiz" will be 
immediately countered with a "Hrm, there's a lot of ambiguity here", as 
you've seen already from those who are perhaps the biggest supporters of D

The detractment of ambiguity should not be underestimated, and can be 
surely be avoided (in this case) with an adjustment here or there?