From 4b3264645adfff14fdb86b53edee57a3ccff9766 Mon Sep 17 00:00:00 2001 From: Julien Couvreur Date: Thu, 17 Apr 2025 01:51:07 -0700 Subject: [PATCH 1/2] Extensions: record decisions from LDM --- proposals/extensions.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/proposals/extensions.md b/proposals/extensions.md index ceb83c56ce..da11331f36 100644 --- a/proposals/extensions.md +++ b/proposals/extensions.md @@ -498,7 +498,7 @@ Types and aliases may not be named "extension". ### Nullability -- Confirm the current design, ie. maximal portability/compatibility +- ~~Confirm the current design, ie. maximal portability/compatibility~~ (answer: yes, LDM 2025-04-17) ```csharp extension([System.Diagnostics.CodeAnalysis.DoesNotReturnIf(false)] bool b) @@ -515,9 +515,9 @@ Types and aliases may not be named "extension". ### Metadata -- Should skeleton methods throw `NotSupportedException` or some other standard exception (right now we do `throw null;`)? -- Should we accept more than one parameter in marker method in metadata (in case new versions add more info)? -- Should the extension marker or speakable implementation methods be marked with special name? +- ~~Should skeleton methods throw `NotSupportedException` or some other standard exception (right now we do `throw null;`)?~~ (answer: yes, LDM 2025-04-17) +- ~~Should we accept more than one parameter in marker method in metadata (in case new versions add more info)?~~ (answer: we can remain strict, LDM 2025-04-17) +- ~~Should the extension marker or speakable implementation methods be marked with special name?~~ (answer: the marker method should be marked with special name and we should check it, but not implementation methods, LDM 2025-04-17) - ~~Should we add `[Extension]` attribute on the static class even when there is no instance extension method inside?~~ (answer: yes, LDM 2025-03-10) - ~~Confirm we should add `[Extension]` attribute to implementation getters and setters too.~~ (answer: no, LDM 2025-03-10) @@ -531,7 +531,7 @@ Types and aliases may not be named "extension". - ~~How to resolve static extension methods?~~ (answer: just like instance extension methods, LDM 2025-03-03) - ~~How to resolve properties?~~ (answered in broad strokes LDM 2025-03-03, but needs follow-up for betterness) - ~~Scoping and shadowing rules for extension parameter and type parameters~~ (answer: in scope of extension block, shadowing disallowed, LDM 2025-03-10) -- How should ORPA apply to new extension methods? +- ~~How should ORPA apply to new extension methods?~~ (answer: treat extension blocks as transparent, the "containing type" for ORPA is the enclosing static class, LDM 2025-04-17) ``` public static class Extensions @@ -619,7 +619,7 @@ static class E ### Accessibility - ~~What is the meaning of accessibility within an extension declaration?~~ (answer: extension declarations do not count as an accessibility scope, LDM 2025-03-17) -- Should we apply the "inconsistent accessibility" check on the receiver parameter even for static members? +- ~~Should we apply the "inconsistent accessibility" check on the receiver parameter even for static members?~~ (answer: yes, LDM 2025-04-17) ```csharp public static class Extensions { @@ -640,7 +640,7 @@ public static class Extensions - ~~Should we relax the type parameter validation (inferrability: all the type parameters must appear in the type of the extension parameter) where there are only methods? This would allow porting 100% of classic extension methods. If you have `TResult M(this TSource source)`, you could port it as `extension(TSource source) { TResult M() ... }`.~~ (answer: no, LDM 2025-03-17) -- Confirm whether init-only accessors should be allowed in extensions +- ~~Confirm whether init-only accessors should be allowed in extensions~~ (answer: okay to disallow for now, LDM 2025-04-17) - ~~Should the only difference in receiver ref-ness be allowed `extension(int receiver) { public void M2() {} }` `extension(ref int receiver) { public void M2() {} }`?~~ (answer: no, keep spec'ed rule, LDM 2025-03-24) - ~~Should we complain about a conflict like this `extension(object receiver) { public int P1 => 1; }` `extension(object receiver) { public int P1 {set{}} }`?~~ (answer: yes, keep spec'ed rule, LDM 2025-03-24) - ~~Should we complain about conflicts between skeleton methods that aren't conflicts between implementation methods?~~ (answer: yes, keep spec'ed rule, LDM 2025-03-24) From 13cf3ad683739be034602b1457d87ce2a48ec16b Mon Sep 17 00:00:00 2001 From: Julien Couvreur Date: Sat, 19 Apr 2025 08:56:22 -0700 Subject: [PATCH 2/2] Lookup on type parameter --- proposals/extensions.md | 1 + 1 file changed, 1 insertion(+) diff --git a/proposals/extensions.md b/proposals/extensions.md index da11331f36..5b819569bb 100644 --- a/proposals/extensions.md +++ b/proposals/extensions.md @@ -615,6 +615,7 @@ static class E } } ``` +- Revisit question of lookup on type parameter ([discussion](https://github.com/dotnet/csharplang/discussions/8696#discussioncomment-12817547)) ### Accessibility