Proposal: func and expr keywords

[chergey]

Present syntax for anonymous delegates (Func<type1, type2, ...> ) and expressions is rather cumbersome.
So I think we need "legitimate" keywords for Func and Expression<Func> (thus, avoiding the necessity to "use" System and System.Linq.Expression namespaces:

func<bool> foo= () => true; //would resolve to Func<bool>
expr<bool> bar = ()=> true; //would resolve to Expression<Func<bool>>

Also, it would be nice to write it even like this (that is, when we will finally have had anonymous delegate type inference):

auto foo = ()=> true; // would default to Func<bool>
expr<auto> bar = ()=> true;
expr<auto, auto> bar = i => Convert.ToBoolean(i);

auto is inferrable type here.

That small feature would make C# look cleaner.

[HaloFour]

func<bool> instead of Func<bool> doesn't seem like much of an improvement. And how often are you really creating an Expression<T>? I've written quite a few helper methods for manipulating expression trees and even I don't find it common enough to warrant special syntax.

As for delegate inference, it suffers the same problem that all delegate inference proposals have: the lack of signature equivalence in the CLR and the overhead of delegate conversion. Also, why auto instead of var? C# doesn't use auto for type inference, C++ does.

[chergey]

Also, why auto instead of var? C# doesn't use auto for type inference, C++ does
Others have pointed that var is reserved for local variables, whereas delegates aren't local.

[HaloFour]

@elcergey

Others have pointed that var is reserved for local variables, whereas delegates aren't local.

auto foo = () => true;

That is the assignment of a local variable.

While var is reserved for local variables now the purpose of the keyword is to convey an implicit/inferred type. Other proposals have sought to extend to use of var beyond locals. Early in the design phase of local functions it was considered to allow the function to return var and allow the return type to be inferred, although hoisting and recursion made that too tricky to be worth implementing. I'd rather reuse an existing keyword that conveys type inference rather than importing another one.

[DavidArno]

I really don't see any significant difference between the two lines:

func<bool> foo= () => true;
Func<bool> foo= () => true;

What would really be of use would be to have the compiler infer the types of Func<> from the usage:

var foo = () => true; // foo is Func<bool>

and to remove the need to specify all generic parameters when some can be inferred, eg:

TR Bar<T, TR>(T p) => default(TR);

var foo = Bar<,bool>(1);