A nice way to step into 2012

[Timon Gehr]

On 12/29/2011 10:19 AM, Don wrote:
> On 28.12.2011 17:41, Jacob Carlborg wrote:
>> On 2011-12-27 23:27, Timon Gehr wrote:
>>> On 12/27/2011 05:25 AM, Andrei Alexandrescu wrote:
>>>> https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Andrei
>>>
>>> Great! =)
>>>
>>> What about making => syntax available to named functions as well?
>>>
>>> class C{
>>> private int x;
>>> int getX() => x;
>>> }
>>>
>>>
>>> void main(){
>>> int[] arr;
>>> bool isOdd(int x) => x&1;
>>> writeln(arr.filter!isOdd());
>>> }
>>>
>>
>> I wouldn't say no to that.
>>
>
> I don't think it improves readability,
> since it doesn't occur in
> arbitrary contexts. It'll always be the only thing on the line.

I think it does, certainly as soon as there are multiple short 
functions. In case the function is used for code generation, it can get 
rid of one level of indentation.

bool isOdd(int x)  { return x & 1; }
bool isEven(int x) { return !isOdd(x); }
bool isPrime(int x){ return x in primes; }

string generate(string x){
     return mixin(X!q{
         @(x) = 2;
     });
}

vs

bool isOdd(int x)   => x & 1;
bool isEven(int x)  => !isOdd(x);
bool isPrime(int x) => x in primes;

string generate(string x) => mixin(X!q{
     @(x) = 2;
});


> I think that example is close to the best case, but
>
> bool isOdd(int x) { return x & 1; }
>
> is not terribly difficult to read.
> So all you're doing is saving 6 characters + one space.

I think it improves both readability and uniformity. Currently we have

         (){...} // anonymous function
void foo(){...} // named function
         () => ...;  // anonymous function

It would make sense to also allow

void foo() => ...; // named function


> The longer the return expression becomes, the less it matters.
>
> real isComplicated(int param1, Foo param2, real param3) => 43.4 *
> foo(param2, bar(param2, param1 + param3 * param3,), 556.4 * param1) +
> param3 + param1 *param2 * param2.baz(param1 + 46, param1*2.46);
>
> doesn't look any more readable than the equivalent code with a return
> statement. Especially not in the member function case.
>

My intention is that it would be used with short expressions. Such 
monster expressions as in your example are rare in real world code.