Proposal: Delegates with suggested parameter names to simplify lambda expressions

[bellagita]

Now the lambda expresion is used a lot, for example with the classic Where extension introduced with Linq:

... EnumerableClass.Where(Element => Element.IsGood()) ...

From System.Linq we have:

public static IEnumerable<TSource> Where<TSource>(this IEnumerable<TSource> source, Func<TSource, bool> predicate);

The Where method wants a predicate that is a delegate of type Func<TSource, bool> that takes in a TSource and returns a bool.

The proposal is to introduce a suggested name in the delegate to use to simplify lambda expressions: Func<TSource value, bool> so we might have:

... EnumerableClass.Where( => value. IsGood()) ...

The compiler sees that the delegate has a suggested name for input variable name of type TSource, and therefore allows you to use in addition to traditional syntax an even more simplified one where there is no need to specify the signature of the Lambda Expression.

[YairHalberstadt]

One lightweight solution in terms of design, language concepts, tooling, and implementation would be to allow one element tuples.

Then you could define your Func as Func<(TSource value), bool> and do _ => _.value.IsGood.

This however would not be backwards compatible.

[yaakov-h]

See also: #91.

I don't think letting the callee define the implicit name for the caller will be a good idea, as you then get into naming conflicts and shadowing, a potential source of bugs.

[Joe4evr]

I don't think letting the callee define the implicit name for the caller will be a good idea, as you then get into naming conflicts and shadowing, a potential source of bugs.

This is less of an issue with C# 8 because lambda parameters that share a name with another variable in scope now auto-shadow that outer variable.

[bellagita]

The real difficulty of this implementation is not a problem of variable name conflict, because the current system of calling with explicit parameter names must always remain optional. In addition, the new form of lambda expressions, with the names of parameters derived from the delegate, must be easily distinguishable from the previous call (perhaps with a different identifier such as !=>).

The difficulty is instead in cases where the context accepts a delegate between different possible types with different signatures, this is a classic when there are different overloads of the same method. Whether the compiler has to choose between different types of delegates with 1, 2 or more parameters. The compiler should see if one or more parameters with the default name were used inside the lambda expression and then identify the correct corresponding delegate. It is not simple but I think it is possible.

Alternatively you could use a form of the type __> instead of => and use the predefined variables in the form _.pameter1 _.parameter2, ... (where "parameterX" was the name suggested in the delegate)

This development would outweigh that done on Kotlin (and #91) where they copied lambda expressions from c # and provided a fixed parameter name for delegates with only one parameter.

I think this new c # enhancement would be very useful because it would bring c # even closer to functional programming!

[bellagita]

Some example:
Instead of having a delegate defined like this:

Func <int, int, int> sum = (x, y) => x + y;

it could be defined as:

Func <int, int x, int y> sum => x + y;

Or:

Func <int, int fast, int furious> andbit => $fast & $furious;

If you want, otherwise the traditional call always remains:

Func <int, int x, int y> mult = (realy, good) => realy * good;