A nice way to step into 2012

[Timon Gehr]

On 01/01/2012 04:39 PM, Don wrote:
> On 31.12.2011 16:58, Timon Gehr wrote:
>> On 12/31/2011 12:51 PM, Don wrote:
>>> On 2011-12-27 23:27, Timon Gehr wrote:
>>>> 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.
>>
>> The indentation is the problem. If you don't like @(x) = 2; then that is
>> an unrelated issue.
>
> It's related. That example is polishing a turd.

I disagree.

> BTW the bit I don't like isn't the @(x) -- that's the best bit! It's the
> "mixin(", the "q{", and the "})".
>

That does not commonly appear in Perl code ;). Anyway, your argument 
against => is that you don't like creative use of the language to be 
supported?

>
>
>>>> 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.
>>
>> On the contrary. The longer the expression, the less it buys you in
>> readability/the less typing it saves.
>>
>>> The BEST CASE is that you save 6 characters, on
>>
>> This is the worst case, if it is applicable. The best case is saving an
>> unbounded amount of characters.
>
> How ??? Each instance of => saves you 6 characters, right?

auto x() => q{
     // 1st line
     // 2nd line
     // 3rd line
     // ...
     // nth line
};

>
>> We should probably stop that discussion soon, because there is no
>> objective readability measure and therefore it is unlikely that one of
>> us will change his opinion.
>
> Before the introduction of =>, I never heard anyone mention about the
> "problem" you're fixing.

There does not need to be a problem to perform further improvements. 
Before the introduction of => there also was no precedent of being able 
to replace {return exp;} by => exp in the language.

> It seems to be a solution in search of problem.
> You can objectively search the newsgroup.

Before the introduction of =>, there was no uniformity problem. I am 
sure this will be brought up again at some point in the future.

>
>> Anyway, it certainly improves language uniformity. Is there any case to
>> be made against generalizing => ?
>
> Yeah.
> (1) *Everything* comes at a cost. It needs to provide a genuine benefit.

It requires some trivial parser changes. And I think it does provide a 
genuine benefit.

> More importantly:
> (2) I do not agree at all that it improves language uniformity. The fact
> that you have to provide a name when declaring a function means it's not
> the same situation at all.
> A function literal is an expression. A function is a declaration.

A function literal is the conflation of a function declaration and a 
symbol lookup. It is both a declaration and an expression.

> The contexts when you use them are completely different.

No. Every function literal can be replaced by a function definition and 
a symbol lookup. And every function definition can be replaced by a 
function literal.


> And the grammer is different.

That is the point. The grammar should be the same, as it was before the 
introduction of =>.


        (int x){return x&1;}
        (int x) => x&1;
int foo(int x){return x&1;}
int foo(int x) => x&1;


>
> It means almost-identical function definitions have completely different
> syntax. This reduces uniformity, and reduces readability.

The same argument could be made against introducing => delegate syntax. 
I don't think it is a valid point.