A nice way to step into 2012

[Don]

On 30.12.2011 01:13, Timon Gehr wrote:
> 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.

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

That just makes it look even more like Perl. The return statement is not 
the problem.

>
>
>> 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.

That's my point. The BEST CASE is that you save 6 characters, on 
something which was already easy to read. I don't think it buys you 
anything in readability. Really, nothing at all.