Added: LDM Notes for March 3rd, 2021

[333fred]

https://github.com/dotnet/csharplang/blob/master/meetings/2021/LDM-2021-03-03.md

Agenda:

1. Natural type for lambdas
   1. Attributes
   2. Return types
   3. Natural delegate types
2. Required members

[huoyaoyuan]

Natural delegate types

Another important note is that by allowing single-method method groups to have a natural type, we'll be taking a step we explicitly avoided in the function pointer feature from C# 9.

The delegate type is quite a pitfall in the .NET type system. There have been several ideas to improve it, for example, something like struct (object, fp*). Assigning a default type of lambda will bother some future improvement, like stackalloc with Span.

[BreyerW]

after reading this

Finally, we looked at whether we should avoid synthesizing delegate types, and just restrict natural types to those that can be expressed as an Action/Func. While this would simplify implementation, it makes understanding the feature dramatically more complex, and prevents using either ref parameters/returns or ref struct parameters/returns.

i was thinking a bit about this and have and idea that maybe is a bit crazy but whatever, since its discussion just spitballing here.

Do you recall proposal to allow ref structs in generics via where T : ref or something like that? I wonder if compiler machinery from this - if ever implemented, that is - with necessary tweaks couldnt be used to allow in, ref etc in generics themselves. The idea is to allow expressing void SomeMethod(in SomeLargeStruct info, ref MutableStructOfArrays storage) as Action<in SomeLargeStruct, ref MutableStructOfArrays>. With ref struct in generics implemented it wouldnt be possible to construct invalid in or ref generic variables if im not mistaken since they will be allowed only when theres no chance to move it to heap (mostly ref structs fields, methods and delegates, very rarely generic on normal class/struct but that generic cant be used to describe fields in them so we are basically back to methods&delegates)

If i remember correctly in variables are ref in disguise and ref are separate types from non-ref but still 'just' a type nonetheless so i think this could work?

[HaloFour]

Ref types are separate types (int& vs int) and it is the runtime that forbids their use as generic type arguments. It makes sense as you'd need different IL to work with ref types than you do with non-ref types, and a generic method can only have one body.

[BreyerW]

@HaloFour if it is runtime that forbids it not compiler then yeah thats ouch. I wonder if thanks to new runtime under NET Core it could be tweaked to allow it. That being said even if it was possible i suspect work needed for this will be not worth it.

[HaloFour]

Regarding lambda natural types, I like it conceptually, as well as the conversion from lambdas and method groups to System.Delegate. I've been bitten myself by some APIs that work like that, although I think generally those APIs used DynamicInvoke internally rather than reflection over the target method. I have some concerns that the router function mapping use case is pretty specific and kind of a one-off, but it's also one that a lot of developers will be exposed to.

My concern, as mentioned, is specifically in the ability to declare an inferred local of a lambda, and the propensity of the inferred type being "wrong". My gut feeling is that where the compiler will infer that the lambda type should be Action<...>/Func<...> that it will be right probably 80-90% of the time. My guess might be a little low, but I also like to declare my own delegate types. I view Action<...>/Func<...> like ValueTuple<...>, great if you have a relatively low number of elements and it's unlikely that they are confused based on their order or type, but that's a different argument altogether. For the cases where the compiler gets it wrong you end up with a delegate type that is incompatible with whatever API you wish to use it with. You have an out, as you always have, by explicitly declaring the target type for the lambda.

My bigger concern is if that feature is extended beyond Action<...>/Func<...> delegates and the compiler synthesizes an unspeakable delegate type. That delegate instance is effectively incompatible with every API that exists except those that accept Delegate, and those are relatively rare. The only other use case would be one where you pass it to a generic method that also accepts a lambda and you intend to invoke the delegate within the lambda, which I imagine is even more rare.

In both cases I believe the language, by adopting local inference of lambdas, will encourage developers to use them and in those cases where the lambda type is incompatible the developer will be more likely to take the easy way out taking another delegate instance to the method group of the incompatible delegate's `Invoke' method, incurring a second allocation and double delegate invocation. That second delegate also breaks reference equality for all of those APIs that expect it, like event handlers, where the compiler-chosen delegate type will never be compatible.

To wrap it up, I believe that the ASP.NET use cases are satisfied without needing to extend natural lambda types to local variable inference. If the developer really wants to declare a local identifier for their routing function they can use a local function instead and pass the method group of that local function to the method.

That's not to say that I don't like the idea of local lambda inference; I really do. But I'd rather evaluate that along with whatever runtime or language changes can support equivalence of delegate types based on signature and without the potential of that effort creating ambiguities or breaking changes in the future.

[alrz]

Can this delegate synthesizer be used for a hypothetical delegate<T, R> type (non-pointer) where they don't have a matching Action/Func?