LDM Notes for October 2nd, 2024

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2024/LDM-2024-10-02.md

Agenda

• Open questions in field
  • readonly contexts and set
  • Conditional code
  • Interface properties and auto-accessors
• Extensions

[DavidArno]

Regarding:

...One possibility is a single pass, that pretends the type parameters from the extension type are part of the method signature. Then we do the same single pass as in extension methods today, and it all behaves the same.

This comes with its own downsides, however, which is breaking a different expectation from C# users around how type parameters work...

One possible approach here is to adopt the two stage approach (it fits with expectations on how type parameters work today), but introduce some syntax that implies "re-run stage 1 here", eg:

public static extension E2<T> for I<T>
{
   public static void M2<T2>(out T2 t) where T2 is T { t = default; }
}

is is used here simply to be a different thing to :. The exact syntax isn't important. It instructs the compiler to re-evaluate T within the context of the method. This would allow for the two stage approach, would maintain consistency with existing behaviour and would solve this use case.

[TahirAhmadov]

Regarding LINQ, I can't see a way to keep it binary compatible. The way forward would be designing new version with the 2 stage process in mind, marking existing extension methods obsolete, and using overload resolution system to prefer the new extensions (albeit I'm not sure right now exactly how to achieve a smooth transition regarding overload resolution - is it the overload priority attribute? )

[CyrusNajmabadi]

Keep in mind that if all else fails, they can always just write it out manually

Then they don't have a safe path forward. The idea is to make it 100% safe so there is no compat concern. If it can potentially break they're not going to risk it.

[CyrusNajmabadi]

This isn't a minor concern. There are literally 20 years of work built in top of extension methods, with all their capabilities and flexibility.

[TahirAhmadov]

The fact that I am convincing a member of LDT to use a generator is hilarious 🤣

I really don't see that big of an issue here. They can quickly inspect the generated extension methods and ensure that the signatures match up. Keep in mind that the code fixer will be doing the conversion; the chances of typos etc are non existent.
Between clearly defined rules, an appropriate level of customization, and the ability to manually write the extension methods to redirect to the new extensions for the edge cases, it's clear to me that this isn't a serious problem to justify degrading the rest of the feature.

[CyrusNajmabadi]

it's clear to me that this isn't a serious problem

this is a primary concern. it may not be to you, but that doesn't change how important it is for the ecosystem as a whole.

[TahirAhmadov]

To clarify, I'm not saying it should be ignored because it's not a problem to me, or that I don't maintain such libraries with extension methods. My point is only that, approaching this with full understanding of the challenge, I think the available solution is satisfactory.

[alrz]

We'd then further be concerned that this would block the BCL from using the new form in conjunction with the old form,

To that end, would it make sense to allow the old form this in extensions instead of for on members? Essentially #7515

due to concerns about the differing inference methodology, as well as other behavioral differences between the forms.

However, I didn't understand how switching between the forms is not a breaking change if there are behavioral differences.

[CyrusNajmabadi]

To that end, would it make sense to allow the old form this in extensions instead of for on members?

Quite possibly. We're dsicussing exactly that.

However, I didn't understand how switching between the forms is not a breaking change if there are behavioral differences.

The main question is: will there be behavioral differences? Or can we ensure users can always use the new form in a way that ensures no behavioral differences.