Added: LDM Notes for April 21st, 2021

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-04-21.md

Agenda

1. Inferred types for lambdas and method groups
2. Improved interpolated strings

[MgSam]

Very glad you guys are willing to take the breaking change for lambda inference. Lack of lambda inference is one of the ugliest warts in modern C#.

[smoothdeveloper]

@MgSam, to better understand, your strong statement, and since I lack context:

• https://github.com/dotnet/csharplang/blob/main/proposals/lambda-improvements.md (which is very terse edit: somehow missed / mixed this link, this page is descriptive)
• Overload resolution and inferred lambda / method group delegate type: potential breaking change #4674 lack real code examples

would you mind expanding about lambda inference issues?

Is it

Func<int> f = () => 1;

Where you need the type annotation (maybe hard to remove that one)?

Or is it a larger thing as I kind of understand about overload resolution ticket, but at the same time, is it frequent to have components with overloads taking delegate types?

Please help me understand the issue.

Also, what are the ugliest warts in premodern C#? (and which is version which cuts modern and premodern for you?).

Thanks!

[MgSam]

Is it
Func<int> f = () => 1;
Yes. Of course this is a simple case. For anything with more parameters it gets really ugly really quickly (and hard to read).

Also, what are the ugliest warts in premodern C#? (and which is version which cuts modern and premodern for you?).

I wouldn't suggest there's a hard line between "modern" and "pre-modern" C#. That said, C# 1.0 didn't have generics, a feature of most modern statically typed languages. It wasn't until C# 3.0 that type inference was added via var, prior to which C# code was the same extremely verbose mess of types it had inherited from Java.

Adding ideas from functional programming have been a big theme for a long time in C#. Iterables (enabling LINQ, a very functional style), immutability, pattern matching are all examples. Easily declaring and composing functions should be part of that, but having lambda functions be a sort of second class citizen where they're harder to assign to variables than other types because of no type inference feels like we're still writing early 2000s era C#.

[HaloFour]

Unfortunately this ends up trading one set of warts for another. Since delegate types are not interchangeable you can't pass these inferred delegates to anything that accepts a delegate type other than Action<...> or Func<...>. And if the lambda uses ref/in/out parameters then the compiler can't reuse any existing delegate type and will emit a custom anonymous one which will be incompatible with every API.

[alrz]

In the past, this feature was known to require runtime changes aka "structural delegate types" I don't know what happened to that discussion.

I think this is the relevant issue dotnet/roslyn#420

[BreyerW]

@HaloFour this is an extra feature that i think could be solved but no need to tie this one and the one you mention. Maybe via synthesizing conversion operators or checking compatibility structurally, but then again the amount of work for that might not be worth it at the moment.