Extract open issues and organize Expressions section #8209

jcouv · 2024-06-12T17:15:46Z

Relates to test plan dotnet/roslyn#66722

jcouv · 2024-06-13T21:31:49Z

proposals/extensions.md

@@ -601,41 +760,61 @@ The preceding rules mean:
 - and that extension methods declared directly in a namespace take precedence
  over extension methods imported into that same namespace with a using namespace directive.

-TODO(static) clarify behavior for extension on `object` or `dynamic` used as `dynamic.M()`?


📝 This is converted to a test with a PROTOTYPE comment about diagnostic quality in PR

…tension

MadsTorgersen

This is a good restructuring! Makes it a lot easier to get an overview on the current state of design, and which are the most pressing issues.

jjonescz · 2024-06-26T14:45:53Z

proposals/extensions.md

+
+Will need to check with the WG as I don't recall the reasoning for this.
+
+## Open issue: need to specify the type erasure design


What's the difference between this and "Open issue: need to specify type erasure" above?

Merged now. Thanks

jjonescz · 2024-06-26T14:49:23Z

proposals/extensions.md

 An *element_access* is dynamically bound if \[...]
 If the *primary_no_array_creation_expression* of an *element_access* is a value of an *array_type*, the *element_access* is an array access. 
-Otherwise, the *primary_no_array_creation_expression* shall be a variable or value of a class, struct, or interface type  TODOTODO
+Otherwise, the *primary_no_array_creation_expression* shall be a variable or value of a class, struct, interface, /***or extension** type


Did you mean to write \* instead of /* ? But I don't know why would that be needed, this seems to work fine:

Suggested change

Otherwise, the *primary_no_array_creation_expression* shall be a variable or value of a class, struct, interface, /***or extension** type

Otherwise, the *primary_no_array_creation_expression* shall be a variable or value of a class, struct, interface, **or extension** type

Applies to other similar changes throughout the doc - I see usages of /* and /[ that were probably meant to be \* and \[ (although the escaping might be actually unnecessary).

Tried again and it looks like the escape sequence is no longer needed. Removed :-)

jjonescz · 2024-06-27T08:32:30Z

proposals/extensions.md

@@ -500,7 +497,7 @@ We modify the [accessibility constraints](https://github.com/dotnet/csharpstanda

 The following accessibility constraints exist:
 - [...]
- \***The underlying type of an extension type shall be at least as accessible as the extension type itself.**
+- ***The underlying type of an extension type shall be at least as accessible as the extension type itself.**


Nit: it seems excessive to use three * - the first is rendered as a literal * and the remaining two make the text bold (at least in the GitHub markdown renderer):

Or was that intended?

This is intended. If found that the bold is not always easy to see, so the * helps spot additions even when the bold isn't.
It looks like GitHub may have adjusted their fonts and the bold seems easier to see than before, but I think it's better to keep for now. It'll be easy to remove if we decide this extra formatting isn't necessary.

jcouv · 2024-06-27T18:40:02Z

@AlekseyTs for review. Thanks

AlekseyTs · 2024-06-28T12:12:58Z

proposals/extensions.md

+
+## Open issue: removing zero-arity-matches-any from var scenario
+
+By the current rules, there are some unfortunate interactions between member access and natural function type.


there are some unfortunate interactions between member access and natural function type

This is not specific. What interactions? Why might one consider them unfortunate? #Closed

See the example below (line 142). A member that cannot work in the end gets in the way. We've taken steps in overload resolution and more recently in natural type to reduce such behaviors (discard bad candidates earlier).
I'm not sure we should do something here, maybe the current behavior is desirable fallout of current rules...

I'm going to remove this open issue. I don't have a good proposal for how to make this scenario work and I'm no longer convinced it should.

Here's an updated summary of the question for the record:

Open issue: removing zero-arity-matches-any from var scenario

By the current rules, a generic method which cannot possibly work in a function type scenario can hide
a member that would work:

var x = C.Member; // error: member lookup finds C.Member (method group) and lacks type arguments to apply to that match class C { public static void Member<T>() { } } implicit extension E for C { public static int Member = 42; }

Is this a scenario we think should work?

For context, from the member access rules,
we perform a member lookup which includes generic methods even when no type arguments are present:

[...] if a member lookup of I in E with K type parameters produces a match, then E.I is evaluated and classified as follows
Note: When the result of such a member lookup is a method group and K is zero,
the method group can contain methods having type parameters.
This allows such methods to be considered for type argument inferencing. end note

See details from the member lookup rules:

When K is zero, methods having type parameters are not removed, since the type inference process might be able to infer the type arguments.

See details on natural type of method groups

AlekseyTs · 2024-06-28T12:49:33Z

proposals/extensions.md

+## Open issue: removing zero-arity-matches-any from var scenario
+
+By the current rules, there are some unfortunate interactions between member access and natural function type.
+> Note: When the result of such a member lookup is a method group and K is zero,


It is not obvious what is the context for the quote (where it is taken from) and how it is relevant to the issue. #Closed

AlekseyTs · 2024-06-28T12:51:02Z

proposals/extensions.md

+> the method group can contain methods having type parameters.
+> This allows such methods to be considered for type argument inferencing. end note
+
+I would like to brainstorm tweaks to member access and natural function type to make this work better.


Better is a subjective term, consider describing the behavior that you think is better. #Closed

AlekseyTs · 2024-06-28T12:52:15Z

proposals/extensions.md

+I would like to brainstorm tweaks to member access and natural function type to make this work better.
+
+```csharp
+var x = C.Member; // error: member lookup finds C.Member (method group) and lacks type arguments to apply to that match


It might help including what does the error say exactly #Closed

AlekseyTs · 2024-06-28T12:56:36Z

proposals/extensions.md

+where `P` is an instance of an extension type on a nullable value type,
+- the spec for an object creation considers whether the type is
+a value_type, a type_parameter, a class_type or a struct_type,
+- the spec for satisfying constraints also consider what kind of type were dealing with.


Typo? "what kind of type were dealing with" #Closed

AlekseyTs · 2024-06-28T12:58:27Z

proposals/extensions.md

+## Open issue: need to specify type erasure
+
+It should be done in a way that allows switching between the extension type and the underlying type without binary break.  
+It should allow for using type parameters as type parameters: `void M<T>(E<T> e)`.  


Did you mean to say: "It should allow for using type parameters as type arguments" ? #Closed

AlekseyTs · 2024-06-28T13:11:34Z

proposals/extensions.md

+The current proposal is to use an attribute with a string representing the type with extensions un-erased.
+For example: `void M(E)` would be emitted as `void M([Attribute("E")] UnderlyingType)`.
+
+The serialization format would be the same as the one used for `typeof` in attributes, but with support for type parameters (using `T!` and `T!!` syntax).  


I thought the proposal was to follow the way specified in ECMA-335 (i.e. to refer by ordinal, rather than by name):

II.9 Generics
Within a generic type definition, its generic parameters are referred to by their index. Generic
parameter zero is referred to as !0, generic parameter one as !1, and so on. Similarly, within the body
of a generic method definition, its generic parameters are referred to by their index; generic parameter
zero is referred to as !!0, generic parameter one as !!1, and so on. #Closed

AlekseyTs · 2024-06-28T13:32:17Z

proposals/extensions.md

+Note: We allow static lookups on type parameters only for members that are static virtual members. 
+Since extensions members are not virtual, we don't allow static extension lookups on type parameters either.
+```
+void M<T>(T t) where T


The constraint is not finished. Did you mean "where T : U"? #Closed

AlekseyTs · 2024-06-28T13:39:14Z

proposals/extensions.md

+- ***When this is used in a primary_expression within an instance method or instance accessor of an extension with a class underlying type,
+  it is classified as a value. The type of the value is the instance type of the extension within which the usage occurs, 
+  and the value is a reference to the object for which the method or accessor was invoked.**
+- ***When this is used in a primary_expression within an instance method or instance accessor of an extension with a struct underlying type, 


Need to specify the meaning for a scenario when the underlying type is a type parameter not known to be a reference type or a value type. #Closed

Yes. I meant to have this as an open issue but forgot. Added.

AlekseyTs · 2024-06-28T13:41:24Z

proposals/extensions.md

+
+A this_access has one of the following meanings:
+- [...]
+- ***When this is used in a primary_expression within an instance method or instance accessor of an extension with a class underlying type,


with a class underlying type

A class underlying type, or an underlying type known to be a reference type? For example, an interface type is not a class and is not a struct, and is not a type parameter. #Closed

AlekseyTs · 2024-06-28T14:00:05Z

Done with review pass (commit 10)

jcouv · 2024-07-09T19:13:34Z

@AlekseyTs Please take another look. Thanks

AlekseyTs

LGTM (commit 11)

jcouv self-assigned this Jun 12, 2024

jcouv commented Jun 13, 2024

View reviewed changes

Extract open issues and organize Expressions section

95bace4

jcouv force-pushed the roles-instances branch from f93e00b to 95bace4 Compare June 17, 2024 23:07

jcouv added 3 commits June 17, 2024 16:17

tweak

8590c6d

Remove preamble section for instance invocations on type parameter ex…

621666b

…tension

more open issues

3559ee1

jcouv marked this pull request as ready for review June 24, 2024 20:55

jcouv requested a review from a team as a code owner June 24, 2024 20:55

typeof question

2cc671f

jcouv requested a review from AlekseyTs June 25, 2024 15:52

ref structs

ef6f0b9

MadsTorgersen approved these changes Jun 25, 2024

View reviewed changes

jjonescz reviewed Jun 26, 2024

View reviewed changes

jcouv added 4 commits June 26, 2024 10:14

Consolidate type erasure sections

912c2e7

Add extension method details

f258e90

fix slashes

dc3c07a

Remove backslashes

8f869f5

jjonescz reviewed Jun 27, 2024

View reviewed changes

AlekseyTs reviewed Jun 28, 2024

View reviewed changes

joscol mentioned this pull request Jul 1, 2024

[BUG]: System.OverflowException in ReviewComment.GetAll octokit/octokit.net#2946

Closed

1 task

Address feedback

b8df62c

jcouv requested a review from AlekseyTs July 2, 2024 18:17

AlekseyTs approved these changes Jul 15, 2024

View reviewed changes

jcouv merged commit 98971c2 into dotnet:main Jul 15, 2024
1 check passed

jcouv deleted the roles-instances branch July 15, 2024 17:18

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Extract open issues and organize Expressions section #8209

Extract open issues and organize Expressions section #8209

jcouv commented Jun 12, 2024 •

edited

Loading

jcouv Jun 13, 2024

MadsTorgersen left a comment

jjonescz Jun 26, 2024

jcouv Jun 26, 2024

jjonescz Jun 26, 2024 •

edited

Loading

jcouv Jun 26, 2024

jjonescz Jun 27, 2024 •

edited

Loading

jcouv Jun 27, 2024

jcouv commented Jun 27, 2024

AlekseyTs Jun 28, 2024 •

edited

Loading

jcouv Jul 2, 2024

jcouv Jul 2, 2024

AlekseyTs Jun 28, 2024 •

edited

Loading

AlekseyTs Jun 28, 2024 •

edited

Loading

AlekseyTs Jun 28, 2024 •

edited

Loading

AlekseyTs Jun 28, 2024 •

edited

Loading

AlekseyTs Jun 28, 2024 •

edited

Loading

AlekseyTs Jun 28, 2024 •

edited

Loading

AlekseyTs Jun 28, 2024 •

edited

Loading

AlekseyTs Jun 28, 2024 •

edited

Loading

jcouv Jul 2, 2024

AlekseyTs Jun 28, 2024 •

edited

Loading

AlekseyTs commented Jun 28, 2024

jcouv commented Jul 9, 2024

AlekseyTs left a comment


		Will need to check with the WG as I don't recall the reasoning for this.

		## Open issue: need to specify the type erasure design

	Otherwise, the primary_no_array_creation_expression shall be a variable or value of a class, struct, interface, /*or extension type
	Otherwise, the primary_no_array_creation_expression shall be a variable or value of a class, struct, interface, or extension type


		## Open issue: removing zero-arity-matches-any from var scenario

		By the current rules, there are some unfortunate interactions between member access and natural function type.

Extract open issues and organize Expressions section #8209

Extract open issues and organize Expressions section #8209

Conversation

jcouv commented Jun 12, 2024 • edited Loading

Choose a reason for hiding this comment

MadsTorgersen left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jjonescz Jun 26, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jjonescz Jun 27, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jcouv commented Jun 27, 2024

AlekseyTs Jun 28, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Open issue: removing zero-arity-matches-any from var scenario

AlekseyTs Jun 28, 2024 • edited Loading

Choose a reason for hiding this comment

AlekseyTs Jun 28, 2024 • edited Loading

Choose a reason for hiding this comment

AlekseyTs Jun 28, 2024 • edited Loading

Choose a reason for hiding this comment

AlekseyTs Jun 28, 2024 • edited Loading

Choose a reason for hiding this comment

AlekseyTs Jun 28, 2024 • edited Loading

Choose a reason for hiding this comment

AlekseyTs Jun 28, 2024 • edited Loading

Choose a reason for hiding this comment

AlekseyTs Jun 28, 2024 • edited Loading

Choose a reason for hiding this comment

AlekseyTs Jun 28, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AlekseyTs Jun 28, 2024 • edited Loading

Choose a reason for hiding this comment

AlekseyTs commented Jun 28, 2024

jcouv commented Jul 9, 2024

AlekseyTs left a comment

Choose a reason for hiding this comment

jcouv commented Jun 12, 2024 •

edited

Loading

jjonescz Jun 26, 2024 •

edited

Loading

jjonescz Jun 27, 2024 •

edited

Loading

AlekseyTs Jun 28, 2024 •

edited

Loading

AlekseyTs Jun 28, 2024 •

edited

Loading

AlekseyTs Jun 28, 2024 •

edited

Loading

AlekseyTs Jun 28, 2024 •

edited

Loading

AlekseyTs Jun 28, 2024 •

edited

Loading

AlekseyTs Jun 28, 2024 •

edited

Loading

AlekseyTs Jun 28, 2024 •

edited

Loading

AlekseyTs Jun 28, 2024 •

edited

Loading

AlekseyTs Jun 28, 2024 •

edited

Loading

AlekseyTs Jun 28, 2024 •

edited

Loading