LDM Notes for June 26th, 2024

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2024/LDM-2024-06-26.md

Agenda

• Extensions

[KennethHoff]

This is something I've been wondering for a while; why do you care so much for not only backwards compatibility, but supporting older compilers? It seems like such a non-scenario to me that someone would use modern C# on a legacy compiler.

[jaredpar]

you don't want to have to rewrite your code simply because you bumped up a compile version

Indeed. Customers have massive amounts of code in various states of support and activity. They don't want couple upgrading to a new .NET SDK or Visual Studo with having to rewrite portions of that code. They simply want to move to the new product.

Can you imagine if new versions of Word forced you to rewrite legacy formatting styles?

[KennethHoff]

Can you imagine if new versions of Word forced you to rewrite legacy formatting styles?

Sure, but this scenario feels more like you trying to use a modern formatting style in Word from 2003. You wouldn't expect that to work.

[CyrusNajmabadi]

Can you imagine if new versions of Word forced you to rewrite legacy formatting styles?

Sure, but this scenario feels more like you trying to use a modern formatting style in Word from 2003. You wouldn't expect that to work.

See my earlier response. If you don't make this available down level, them you greatly impede the ability for people (especially library authors) to actually use and benefit from this feature.

It will take many years for the ecosystem to move to c#13 or above. If extensions don't work down level then people will not adopt them as it will shut out a large percentage of their user base.

Your question was why care about forward compat. This is the reason why. :-)

[CyrusNajmabadi]

It seems like such a non-scenario to me that someone would use modern C# on a legacy compiler.

This is not a non-scenario. This is the Norm. Libraries move forward and release new versions of a lib built in the latest c#. Consumers of the library upgrade to that while not upgrading their language version for a long while.

What you describe as a non-scenario is actually the opposite :-)

[KennethHoff]

I think I understand the forward compatibility story now. Here's an analogy with CSS.

CSS Cascade layers, despite releasing many years ago, still is practically unused because it has non-existent forward comparability. Cascade Layers is one of the few things in CSS that fundamentally don't work unless you implement support for it (i.e. all unsupported browsers fully break).

If C# didn't prioritize forward compatibility, all new features would suffer from this, I reckon.

---

I still don't understand the Word analogy though 🤔

[TahirAhmadov]

Regarding the "signature uniqueness", now that we're emitting stuff on the extension's underlying static class to prevent direct invocations for non-instance-method members, is it possible to also output some modifier on the static extension method (in the current runtime) which would differentiate the signature in some way?
I'm guessing emitting extension static methods with mangled names is a non-starter, because it would break the expected behavior for reflection users :(
What about outright prohibiting such situations?
PS. Finally, can the instance extension methods be output with the this parameter being a wrapper ref struct? I can also imagine reflection issues with it, though. And it's no longer fully backwards compatible with old extension methods.