Added: LDM Notes for May 10th, 2021

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-05-10.md

Agenda

• Lambda improvements

[AartBluestoke]

"
-Delegate types that inherit from System.Delegate.
-Expression tree types that inherit from System.Linq.Expressions.**Expression.
-Function pointer types.
All of these types support conversions from some subset of method groups or lambdas, and none is currently privileged above another."

Expressions are second class citizens- according to https://github.com/dotnet/corefx/issues/33170 System.Linq.Expressions is archived meaning:

"When archived, we would not accept features contributions to the packages. We would consider changes that address significant bugs or regressions, or changes that are necessary to continue shipping the binaries. Other changes will be rejected."

several tickets to 'can we please have expressions do this thing also' have been closed as 'won't fix', or have hung for years after that has been pointed out. Could we have a statement from the group on what they consider the position of expressions within the language is, and if expressions are first class or second class citizens?

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-04-07.md#expression-trees

[MgSam]

Now that you guys have affirmed Action/Func/synthesized delegate as the "natural type" of lambdas, maybe now its time to consider whether a type-only version should be allowed in type positions as well? (A la TypeScript)

public (string s, int i) => int Foo()
{
     return ( s, i) => 42;
}

equivalent to

public Func<string, int, int> Foo()
{
    return (s, i) => 42;
}

Of course this is a little weird given the other C# 10 decision to allow return types on lambdas but put them in the front. Given that, maybe a "type-only" lambda looks more like this? int (string s, int i) => {}

Either way, I think this is worth considering as these anonymous lambdas have more descriptive parameter names and are also more natural to read than Func or Action.

[alrz]

We already have a syntax for function types delegate<string, int, int> (just drop * from function pointers)

[MgSam]

Good point, though we have no way of specifying argument names with that syntax currently.

[Unknown6656]

Good point, though we have no way of specifying argument names with that syntax currently.

@MgSam This could solved using #3814, #1883, or #3703

[MgSam]

@Unknown6656 I agree named generic type parameters could be a good solution here, though the IDE would still need to do some kind of magic to realize how those type parameters correspond to the actual function parameters / return types.

[Unknown6656]

Why should var m = (x => x); not work?
One could allow m to be a generic delegate of the type delegate<T, T> -- comparable to F#. This would allow the invocation of m(42), m(4.2f), or m("42").

[HaloFour]

I think that's opening a can of worms. What does this mean then?

var m = (x => x + x);

[orthoxerox]

I think that's opening a can of worms. What does this mean then?

var m = (x => x + x);

delegate<T, U> where T : interface<T, U> { static U operator+ (T, T); }