proposal: short => rewrite for function declarations

[Steven Schveighoffer]

On 10/11/20 12:04 PM, Timon Gehr wrote:
> On 11.10.20 17:43, Adam D. Ruppe wrote:
>> On Sunday, 11 October 2020 at 15:38:26 UTC, Timon Gehr wrote:
>>> Why add incidental complexity like this all?
>>
>> That's why I kept the two commits separate. I'm not in love with it 
>> either but if it is what people want,
> 
> My point was that nobody should want that.
> 
> alias bar0=(v)=>v;

In here, v is a parameter name.

> void foo0(v)=>v; // why special-case this,

here, v is a type, and this is not a valid function (functions cannot 
return types). We are not talking about invalid functions, but valid ones.

> 
> alias bar1=(v){ return v; }
> void foo1(v){ return v; } // but not this?

For a function declaration, if you want a templated value, you have to 
declare the template parameter. There is no short-hand syntax, like for 
lambdas.

> void baz0(int){ return 2; } // why is this fine,
> void baz1(int)=>2;          // but this is not?
> 
> alias baz2=(int)=>2;        // and this is allowed!

Lol, that last one, it only "works" because it's a keyword.

try this instead:

alias Int = int;

alias baz3= (Int) => 2;

baz3("hello"); // compiles, it's a function with a templated parameter 
named Int.
baz2("hello"); // error

Why make it not work? Because we have an opportunity to alleviate the 
confusion when introducing a new feature. We can relax it later if it 
makes sense to. But we can't impose a rule later that breaks code. Right 
now, no compiling code will be broken by this restriction.

> The complaint is _orthogonal_ to what's being discussed.
> This would add another special case just for the sake of making the 
> language specification a bit longer.

To prevent confusion and inconsistency.

these two are equivalent "function-like" things:

alias x= (T t) => expr;
auto x(T t) { return expr;}

These two are not:

alias x = (t) => expr; // t is a parameter
auto x(t) => expr; // t is a type

> (args)=>e is a shorthand for (args){ return e; } and this is a simple, 
> consistent rule. What happens later in semantic is not the business of 
> the parser.

I don't think it needs to be a parser error.

-Steve