== Quote from Andrei Alexandrescu ([email protected])'s article
> On 9/22/11 10:42 AM, pillsy wrote:
> > == Quote from Andrei Alexandrescu ([email protected])'s article
[...]
> >> Already does. We're looking for a briefer syntax.
> > What is the problem with just inferring the `return`, allowing you to
> > replace
> > (a,b) { return a + b; }
> > with
> > (a, b) { a + b; }
> > This seems competitive with the other syntaxes for brevity, but ISTR there
> > was
> > some objection to doing things that way.
> The objection is that it introduces a number of questions:
At the risk of relitigating a long-settled issue, I think there are good
answers to all these questions.
> 1. How about using that syntax in regular functions?
That sounds great! :)
> 2. What if the lambda wants to actually evaluate the expression but
> return void?
Is this commonly important? If so, there are three possibilities:
a. Have an expression with type void, perhaps a `void` literal or empty
patens `()`, that can be used as the
ultimate expression when needed, as in
(i) { total += i; void; }
b. Require the use of a bare `return` in these cases.
c. Require the return type to be explicitly declared as void in those
cases. This seems like it's especially not a
problem for named functions, since `void` isn't any longer than `auto.
> 3. How is the semicolon relevant? (If its presence is used as a
> disambiguator for (2), it's poor design to predicate a large semantic
> difference on such a distinction.)
It's just part of the syntax. I agree that using it to disambiguate the
function's return type is horrible. Mathematica
does that, and I've torn out a fair amount of my hair because of it over the
years.
[...]
> > I'm not exactly a D template metaprogramming pro, but I think this would
> > work for a lot of common cases.
> Such an approach has caused more trouble than benefits in C++.
Fair enough.
Cheers, Pillsy
