LDM Notes for June 12th, 2024

[333fred]

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

Agenda

• params Span breaks
• Extensions

[KennethHoff]

Referencing the emit strategy of extensions; would it be possible to - in the future when runtime support is needed with interfaces - to replace the emit strategy of extensions to be option 1, given that it's generally speaking preferable, or is that a breaking change? ( Reflection break notwithstanding, of course).

Is there precedent for changing how a language feature is emitted after the fact? I'm just worried that we'll end up in a worse place just because the LDM didn't want to delay the release a couple of years (I realize that it will not be a good PR stunt to do so), as proposed in option 1. What I mean is then this; Preview as statics in 9&10, and then fully commit to runtime support in 11(/12/13/??) for the entire feature set.

[333fred]

I want to see the approach to be future proof.

I think it would be more disappointing if this emit strategy limits the capabilities of extensions in the future

I think I was pretty clear in the notes that we see both strategies as future-proof.

[huoyaoyuan]

I think I was pretty clear in the notes that we see both strategies as future-proof.

My question is that, when we eventually get runtime support with interface implementation, how would the extensions lowered into methods integrate with the new mechanism?
Being consistent with old extension methods is good so that it doesn't increase the problem.

[333fred]

Quoting directly from the notes:

We also don't think the runtime work to support extensions implementing interfaces for these types would be prohibitively more expensive than option 1; to the runtime, a static method that takes an object as its first parameter is very similar to an instance method on that object. While it wouldn't be as immediately straightforward as an instance member on an extension type, we also don't think it will be too challenging, especially since we expect to need runtime support for the interface implementation part anyways.

[huoyaoyuan]

a static method that takes an object as its first parameter is very similar to an instance method on that object

But it's not exactly the same, as https://minidump.net/c-why-function-pointers-cant-be-used-on-instance-methods-8a99fc99b040/ points out. I'm concerning about it to become a blocker in the future.

[HaloFour]

I think that article is trying to point out that from the outside you can't make assumptions as to the calling convention decisions being made by the runtime. But the runtime itself could make decisions that treat these static methods identically to how it would treat instance methods.

[TahirAhmadov]

Regarding params Span and expression trees, question: expression trees don't support it now, or can't ever support it? And if it's the former, why not take that first step on the long over-due expression tree "upgrade"? And if it's the latter, can we learn about why? Thank you.

[KennethHoff]

And if it's the former, why not take that first step on the long over-due expression tree "upgrade"?

Because there is no "first step" that can be meaningfully split off.

I was under the impression that the plan (or at least a plan) was to create an entirely new namespace for the new-and-improved Expression trees, and leave the old one behind. Given that, defining that namespace and how to use it would be an obvious first step.

I think Cyrus mentioned it once, at least, as a possible solution

[HaloFour]

I honestly wish the language team would just pull the trigger with expression tree evolution. Developers already need to know what subset of the BCL they can safely use with any given queryable provider, I don't think language features really need be treated that differently. In either case, the longer this goes, the worse it gets and the trickier any possible solutions would end up being.

[TonyValenti]

Ive never rolled my own expression tree code or Roslyn code so this might be a dumb question, but...

Why aren't expression trees implemented as results from a "parse c# code" function?
It seems to me like there should be a lot of code shared by the c# parser and expressions.

[HaloFour]

Expression trees are language agnostic and were designed well before Roslyn and it's concept of expression trees. They're intended to be consumed by general purpose frameworks that largely shouldn't have to be aware of the compiler that was used to emit them.

I am very curious as to what discussions, if any, took place during the design of LINQ as to how expressions would evolve. I can't imagine anyone at the time assumed that there would never be a need to add more expression node types, and nobody should have designed a framework assuming that it was a closed hierarchy.

[MgSam]

Is that the reason for the hesitancy to add new expression node types? That existing libraries wouldn't know how to handle them?