meetings/2025/LDM-2025-03-03.md
Champion issue: https://github.com/dotnet/csharplang/issues/8697
Specification: https://github.com/dotnet/csharplang/blob/975ef97651519ccfdcb569c92c74d695afc054c1/proposals/extensions.md
Today, we looked at more open issues in extensions. This time, we looked at a few specific questions from the proposal.
We should follow-up on "factory scenario" where multiple extension declarations have static factory methods with same parameter types but different return types.
This scenario looks something like this:
public static class Factory
{
extension(A)
{
public static A Create() => ...;
}
extension(B)
{
public static B Create() => ...;
}
}
By the existing rules, this would be blocked: C# methods cannot differ just by return type (though they can in IL). There may even be
scenarios where two static methods on different underlying types may have exactly the same signature, with the same return type, which
is definitely not expressible in IL without help, namely in the form of a modopt or modreq on the signature to differentiate them.
If we wanted to try and allow this in the future via modopt/modreqs on the return type, we would have to start doing that now; it is
a binary-breaking change to change the modopt/modreqs on a member, and we do not want to end up in a scenario where a user might
break binary compat simply by adding an entirely unrelated member. There's also a concern that using modopts would mean that you can't
move from an extension static method to a regular static method (or vice versa) without a binary break. Making the static extension
member a regular static member on the type (perhaps in response to a downstream library adding the method you were polyfilling) would
become a binary breaking change, and we have some hesitance about doing that. Another option would be to mangle the names of these members
somehow, however we think that these static extension members should be speakable for disambiguation purposes, and we don't want to have
to expose some bespoke mapping from what appears to be a standard static method to a complex naming scheme.
Part of what's driving this scenario is that extension blocks feel like different scopes. They have braces, so we believe that it's
natural to assume that you can overload across them without issue. This does break down somewhat when examined closely: you can have
multiple extension blocks for the same type, so would that mean that each block can overload on the same extended type? However, this
natural inclination seems somewhat reasonable to us, as does having a single static class devoted to having factory methods for a number
of different underlying types. Given this, we want to explore the modopt approach. The working group will do so, and come back to us
with the consequences of this decision. That being said, we do feel that we are leaning towards blocks not actually being different
scopes. They do seem like it at first glance, but the decisions we've made around them so far are leaning towards them not being real
scopes.
Next, we turned our attention to member lookup, especially for static methods, and for when properties are combined with methods.
We largely agree with the rules proposed, and our discussion from the first question and from last time.
We want these to be standard methods, so applying standard rules in other aspects makes sense and is consistent. We value that consistency
argument, and so we want to use the same rules as much as possible. This means standard lookup for static extensions scenarios, and if
lookup finds both properties and methods in the same set, that's an error. We can potentially look at improvements to the method vs
property scenario later, if we find that it is a problem in practice, but we don't expect it to be. We'll have a formal specese version
of these rules to review later, but for now, they are tentative accepted as proposed.