Add proposal for partial type inference #7582

TomatorCZ · 2023-10-07T11:25:39Z

No description provided.

jcouv · 2023-10-16T16:52:37Z

Sorry for the delay. We've focused on wrapping up C# 12 bugs. We'll look in a few weeks. Thanks

proposals/partial-type-inference.md

jcouv · 2023-11-02T20:29:49Z

proposals/partial-type-inference.md

+## Summary
+[summary]: #summary
+
+Partial type inference introduces a syntax skipping obvious type arguments in the argument list of


obvious

nit: instead of "obvious" consider "inferrable" (also applies below) #Closed

Should be fixed by commit 33b71f0

proposals/partial-type-inference.md

jcouv · 2023-11-02T20:38:27Z

proposals/partial-type-inference.md

+  > Example
+  > 
+  > ```csharp
+  > var wrappedData = Create(new MyData());


nit: Do we need this line to illustrate the point?
I think the line below (return new Wrapper<T>(item);) is central and sufficient #Closed

Should be fixed by commit 5e59e96

jcouv · 2023-11-02T20:41:07Z

proposals/partial-type-inference.md

+  > class Wrapper<T> { public Wrapper(T item) { ... } }
+  > ```
+
+  2. Cases where the method type inference would be weak. (Using type info from target type, or type arguments' constrains)


Suggested change

2. Cases where the method type inference would be weak. (Using type info from target type, or type arguments' constrains)

2. Cases where the method type inference would be weak. (Using type info from target type, or type constraints)

typo: constrains -> constraints, also applies in other locations below #Closed

Should be fixed by commit 33b71f0

proposals/partial-type-inference.md

jcouv · 2023-11-02T20:53:28Z

proposals/partial-type-inference.md

+- The semantics of an identifier named `_` depends on the context in which it appears:
+  - It can denote a named program element, such as a variable, class, or method, or
+  - It can denote a discard ([§9.2.9.1](https://github.com/dotnet/csharpstandard/blob/draft-v7/standard/variables.md#9291-discards)).
+  - **It can denote an inferred type argument avoiding specifying type arguments which can be inferred by the compiler.**


Can be simplified

Suggested change

- **It can denote an inferred type argument avoiding specifying type arguments which can be inferred by the compiler.**

- **It can denote a type argument to be inferred.**

``` #Closed

Should be fixed by commit 33b71f0

jcouv · 2023-11-02T21:56:36Z

proposals/partial-type-inference.md

+> Specification: Original section changed in the following way
+
+* We change the meaning of the content of *type_argument_list* in two contexts.
+  * [Constructed types](https://github.com/dotnet/csharpstandard/blob/draft-v7/standard/types.md#84-constructed-types) occuring in [*object_creation_expression*](https://github.com/dotnet/csharpstandard/blob/draft-v7/standard/expressions.md#128162-object-creation-expressions)


As a general comment, I appreciate the references back to the standard/spec. The format you adopted in other sections (copy a paragraph from original spec and add some highlighted edits) is really nice. But when I look at "Type arguments" section, it's not clear which section of the spec is being edited.

Maybe you mean to edit section 8.4.2 ("type arguments")? That seems to be the right place to introduce inferred_type_argument into the type_argument_list grammar.
(If so, then the references to "constructed types" (8.4) and "object_creation_expression" could be removed)

Below is a possible grammar change to introduce inferred_type_argument:

type_argument_list : '<' type_arguments '>' ; type_arguments // modified : type_argument (',' type_arguments) | inferred_type_argument (',' type_arguments) ; type_argument : type ; inferred_type_argument // new : '_' ;

Then we can say that inferred_type_argument is only allowed in the contexts that you listed.

We still need to resolve the issue of back compat:

public class _ { } public class C<T> { public void M(C<_> x) { } // allowed today }

We'll need to decide whether the presence of an existing type named "" in scope affects the interpretation of "" in type argument lists, or whether "" always means "inferred type argument" (ie. we take a compat break, maybe warn on types named "").

Should be fixed by 6039b9f.

jcouv · 2023-11-02T22:19:54Z

proposals/partial-type-inference.md

+  > {
+  >     void M() 
+  >     {
+  >         new C1<>( ... ); // Refers generic_inferred type C1<T>


T, T1 and T2 don't exist here.
Reading ahead to the "Object creation expressions" section, I believe the comments in this snippet are not what you intended and some actual types should be inferred from inspecting candidate constructors. #Closed

Should be fixed by commit b6081e3

proposals/partial-type-inference.md

jaredpar · 2023-11-03T18:03:31Z

proposals/partial-type-inference.md

+  > ```
+
+  The first improvement, which would improve the method type inference algorithm, has a significant disadvantage of the breaking change.
+  On the other hand, the second improvement, which would enable specifying some of the method's type arguments, does not influence old code, solves problems regarding the "all or nothing" principle, and reduces the first weakness.


I'm unclear what the "all or nothing" principle means here. #Resolved

Line 58 explains "all or nothing" principle. The method type inference infers either all of the type arguments or nothing (e.g. we can't hint the compiler some of the type arguments).

In line 68, wouldn't it even be possible to infer twice: test<TestCaseDefault<_>, _>(new MyData()); ?

Sure, it would be possible, I will fix it during the weekend. (Commit 98d835e)
Thank you

jaredpar · 2023-11-03T18:08:06Z

proposals/partial-type-inference.md

+- The semantics of an identifier named `_` depends on the context in which it appears:
+  - It can denote a named program element, such as a variable, class, or method, or
+  - It can denote a discard (§9.2.9.1).
+  - \***It can denote an inferred type argument avoiding specifying type arguments which can be inferred by the compiler.**


Rather than it can I'd prefer the language it will. Essentially when flipping to /langversion:X where X is the release that introduces this feature, I'd prefer the meaning to be unambiguous. That is for the case M<_, object>(42, null), the _ unambiguously means an inferred type parameter.

Yes this would be breaking change to developers who defined class _ { } but that seems like a minority case. It in the same ballpark as class record which we broke when introducing records.
#Resolved

Should be fixed by commit 33b71f0

TomatorCZ · 2023-11-03T18:52:51Z

Thank you for all comments. I will revise the proposal during the weekend.

proposals/partial-type-inference.md

Co-authored-by: Julien Couvreur <[email protected]>

Co-authored-by: Jared Parsons <[email protected]>

Co-authored-by: Julien Couvreur <[email protected]>

…during type inference as alternatives

TomatorCZ · 2023-11-05T18:37:54Z

Done with the first round of revisions.

TomatorCZ · 2024-01-15T18:38:07Z

Hi,

I implemented a prototype which passes Test.cmd -testCompilerOnly tests(except the ones, which fail in main on which the change is rebased on). See fork. The implementation is rather a proof of concept than ready to production code.

Probably the most interesting file contains tests for the partial type inference.

The implementation contains the mentioned design in the proposal without 2. and 3. parts mentioned here

RikkiGibson · 2024-01-17T00:19:55Z

proposals/partial-type-inference.md

+  >
+  > ```csharp
+  > object data = database.fetch();
+  > int count = data.Field("count"); // Error, method type inference can't infer the return type. We have to specify the type argument.


Consider breaking the examples up across more lines in general. For example, here put the comment above the statement instead of trailing it on the same line.

GitHub requires to horizontally scroll the code samples at about 115 characters in a line, and when the samples are presented to LDM, maybe even fewer, as the font size will be larger.

Should be fixed by commit e973d80

RikkiGibson · 2024-01-17T00:24:06Z

proposals/partial-type-inference.md

+  ;
+```
+
+* When a type with `_` identifier is presented in the scope where **inferred_type_argument** is used, a warning should appear since the **inferred_type_argument** hides the type's name causing a breaking change.


How should the user resolve this warning if it appears?

It will mostly occur in pre-existing code. If user desires the "old meaning", then perhaps changing _ to @_ is the proper advice.

If the warning occurs, but inferred_type_argument is actually desired, the user probably needs to suppress the warning, or possibly adjust using-directives etc.

Should be fixed by commit 4485ab9

RikkiGibson · 2024-01-17T00:32:13Z

proposals/partial-type-inference.md

+
+> Specification: Original section changed in the following way
+
+We change the [type inference](https://github.com/dotnet/csharpstandard/blob/draft-v7/standard/expressions.md#1263-type-inference) as follows.


It looks like the below section is entirely new. If the below section is entirely new, please state here that it is being added to the type inference section.

If there is a combination of adding new language and updating existing language, please use bold for the newly-added parts, and non-bold for the pre-existing parts.

Should by fixed by commit 9dfa24f

proposals/partial-type-inference.md

RikkiGibson · 2024-01-17T22:57:16Z

proposals/partial-type-inference.md

+
+#### Type inference algorithm change
+
+> Specification: Original section changed in the following way.


Please use block quotes only for when we are quoting from another source. Also, let's indicate here that the specification change is followed by an explanation of the change.

Basically, looking at this spec language on its own, without the explanation, is more challenging, and it may be reasonable for the reader to simply skim the spec change, then review the explanation, then finally go back to the spec change in order to fully understand.

Should be fixed by commit 7aa277e

Co-authored-by: Rikki Gibson <[email protected]>

TomatorCZ · 2024-02-03T22:00:09Z

Done with the second round of revisions.

proposals/partial-type-inference.md

Co-authored-by: Rikki Gibson <[email protected]>

1. top level _ in method inv and creating object expr 2. nested _ in method inv and creating object expr

RikkiGibson · 2024-04-16T17:04:38Z

proposals/partial-type-inference-v2.md

@@ -160,7 +160,7 @@ The initial set of candidate methods for is changed by adding new condition.
 - If `F` is generic and `M` has no type argument list, `F` is a candidate when:
  - Type inference (§12.6.3) succeeds, inferring a list of type arguments for the call, and
  - Once the inferred type arguments are substituted for the corresponding method type parameters, all constructed types in the parameter list of `F` satisfy their constraints ([§8.4.5](https://github.com/dotnet/csharpstandard/blob/draft-v7/standard/types.md#845-satisfying-constraints)), and the parameter list of `F` is applicable with respect to `A` (§12.6.4.2)
- **If `F` is generic and `M` has a type argument list containing at least one *inferred_type* or *partial_inferred_type*, `F` is a candidate when:**
+- **If `F` is generic and `M` is *partial_inferred*, `F` is a candidate when:**
  - **Method type inference (See the [Type Inference] section) succeeds, inferring the type arguments list for the call, and**


Was Type Inference meant to be a link here?

https://github.com/dotnet/csharplang/pull/7582/files#diff-79921a867e573503f54d5a13d465b08a27cf745e8ed47b914438e95fd17a4edcR139

It's just a name for these types of expressions (M<_, List<_>>(...))

RikkiGibson · 2024-04-16T17:17:47Z

proposals/partial-type-inference-v2.md

+- If `T` is a *value_type* and `A` is not present:
+  - **The *object_creation_expression* is a default constructor invocation.**
+    - **If the type is *partial_inferred*, Constructor type inference (See the [Type Inference] section) of the default constructor occurs to determine closed type. If it succeeded, construct the type using the inferred type arguments. If it failed the binding-time error occurs.**
+    - **If the type inference above succeeded or the type is not inferred, the result of the *object_creation_expression* is a value of (constructed) type `T`, namely the default value for `T` as defined in [§8.3.3](https://github.com/dotnet/csharpstandard/blob/draft-v7/standard/types.md#833-default-constructors).**


I'm conflicted about having these lines here because:

they are out of date (new ValueType() can be invocation of a parameterless (explicitly declared) struct constructor).

the described inference will never succeed. Perhaps in future if target type contributes to inference, but not with this version of the feature.

I think for the purposes of this feature speclet we could delete these lines and just remove "Otherwise," from the "Otherwise, if T is a type parameter"... below.

RikkiGibson · 2024-04-16T18:10:44Z

proposals/partial-type-inference-v2.md

+F<C<_>, int>( ... ); // C<_> represents an inferred type.
+new C<C<_>, int>( ... ); // C<C<_>, int> represents an inferred type.
+C<_> temp = ...; // _ nor C<_> doesn't represent an inferred type.
+new _( ... ); // _ doesn't represent an inferred type.


LDM will want to talk in more details about the breaking change here, exactly what will _ mean in each context, and so on.

I feel like we should consider breaking _ whenever it is used in a type position. Even if it makes no sense here, I think it is better for readability of the code if _ in new _() does not refer to a different thing than _ in new C<_>(), in the same scope.

This search gives me some confidence that the breaks caused by this approach are acceptable: https://grep.app/search?q=public.%2A%28class%7Cstruct%7Cinterface%7Cenum%29%20_%5Cs&regexp=true&filter[lang][0]=C%23

RikkiGibson · 2024-04-16T18:15:17Z

proposals/partial-type-inference-v2.md

+
+* A type is said to be *partial_inferred* if it is *inferred_type_placeholder* or *partial_inferred_type*. 
+
+* When a type with the `_` identifier is presented in the scope where *inferred_type_placeholder* is used, a warning should appear since the *inferred_type_placeholder* hides the type's name causing a breaking change. 


If we can, we should start issuing a warning on declaring or using a type named _ in the previous language version to let people know this change is coming. (where changing to @_ suppresses the warning and doesn't get flagged in analyzers for detecting unnecessary @.)

Hopefully we can separate this question of whether/how to adjust behavior of _ for discards, while leaving space for them to eventually both work in a coherent manner. (IIRC, fixing the quirks around _ is one of the more often discussed breaking changes, see #7189)

RikkiGibson · 2024-04-16T18:26:56Z

proposals/partial-type-inference-v2.md

+
+We change the [compile-time checking](https://github.com/dotnet/csharpstandard/blob/draft-v7/standard/expressions.md#1265-compile-time-checking-of-dynamic-member-invocation).
+
+- First, if `F` is a generic method and type arguments were provided, then if the method group is *partial_inferred*, an binding error occurs since it is not supported in the runtime binding.


We will likely decide to perform a partial inference at compile time when a single candidate is found for the dynamic invocation. It's not urgent to revise this proposal to get this precisely right. Certain details of this may be subject to change. See https://github.com/dotnet/csharplang/blob/main/proposals/params-collections.md#dynamic-vs-static-binding.

Partial type inference

df50582

TomatorCZ requested a review from a team as a code owner October 7, 2023 11:25

333fred requested a review from jcouv October 9, 2023 16:35

333fred assigned jcouv Oct 9, 2023

RikkiGibson self-assigned this Oct 9, 2023

jcouv reviewed Nov 2, 2023

View reviewed changes

proposals/partial-type-inference.md Outdated Show resolved Hide resolved

jcouv reviewed Nov 2, 2023

View reviewed changes

proposals/partial-type-inference.md Outdated Show resolved Hide resolved

jcouv reviewed Nov 2, 2023

View reviewed changes

proposals/partial-type-inference.md Outdated Show resolved Hide resolved

jcouv reviewed Nov 2, 2023

View reviewed changes

jcouv added 2 commits November 2, 2023 15:09

Update partial-type-inference.md

6e3c0cb

Remove header template

afc1eca

jcouv reviewed Nov 2, 2023

View reviewed changes

proposals/partial-type-inference.md Show resolved Hide resolved

jaredpar reviewed Nov 3, 2023

View reviewed changes

jcouv reviewed Nov 3, 2023

View reviewed changes

proposals/partial-type-inference.md Show resolved Hide resolved

TomatorCZ and others added 8 commits November 4, 2023 22:47

fix typo

44bf3a2

Co-authored-by: Julien Couvreur <[email protected]>

fix typo

54ee1c4

Co-authored-by: Jared Parsons <[email protected]>

change wording

469a112

Co-authored-by: Julien Couvreur <[email protected]>

change wording and fix typo

33b71f0

delete unnecessary part of example

5e59e96

change formulation of type_name meaning

b6081e3

change grammar of type argument section

6039b9f

make type inference using initializers and types with floating arity …

ea87f2f

…during type inference as alternatives

RikkiGibson reviewed Jan 31, 2024

View reviewed changes

TomatorCZ and others added 10 commits February 3, 2024 11:48

typo

8c7eadb

Co-authored-by: Rikki Gibson <[email protected]>

typo

ebe9eaf

Co-authored-by: Rikki Gibson <[email protected]>

type

47524ae

Co-authored-by: Rikki Gibson <[email protected]>

Merge branch 'dotnet:main' into main

8db3728

typo

9daa672

shrink comments in code examples

e973d80

add possible resolutions of _ used as a typename

4485ab9

typo

524a491

make changes regarding type inference more clear

9dfa24f

remove block quotes

7aa277e

RikkiGibson reviewed Feb 7, 2024

View reviewed changes

proposals/partial-type-inference.md Outdated Show resolved Hide resolved

TomatorCZ and others added 5 commits March 13, 2024 15:45

fix code example

e9b827b

Update proposals/partial-type-inference.md

87cc926

Co-authored-by: Rikki Gibson <[email protected]>

move nullability to type arguments section

98d835e

Add proposal containing just

be609af

1. top level _ in method inv and creating object expr 2. nested _ in method inv and creating object expr

typo

2537f53

RikkiGibson reviewed Apr 16, 2024

View reviewed changes

typo

254b137

RikkiGibson reviewed Apr 16, 2024

View reviewed changes

Tomáš Husák added 3 commits April 16, 2024 19:26

adjust object creation expression binding

4f01563

typo

fe31185

remove outdated explanation

e20b17a

RikkiGibson reviewed Apr 16, 2024

View reviewed changes

	2. Cases where the method type inference would be weak. (Using type info from target type, or type arguments' constrains)
	2. Cases where the method type inference would be weak. (Using type info from target type, or type constraints)

	- It can denote an inferred type argument avoiding specifying type arguments which can be inferred by the compiler.
	- It can denote a type argument to be inferred.
	``` #Closed


		> Specification: Original section changed in the following way

		We change the [type inference](https://github.com/dotnet/csharpstandard/blob/draft-v7/standard/expressions.md#1263-type-inference) as follows.


		#### Type inference algorithm change

		> Specification: Original section changed in the following way.


		* A type is said to be partial_inferred if it is inferred_type_placeholder or partial_inferred_type.

		* When a type with the `_` identifier is presented in the scope where inferred_type_placeholder is used, a warning should appear since the inferred_type_placeholder hides the type's name causing a breaking change.


		We change the [compile-time checking](https://github.com/dotnet/csharpstandard/blob/draft-v7/standard/expressions.md#1265-compile-time-checking-of-dynamic-member-invocation).

		- First, if `F` is a generic method and type arguments were provided, then if the method group is partial_inferred, an binding error occurs since it is not supported in the runtime binding.

Add proposal for partial type inference #7582

Are you sure you want to change the base?

Add proposal for partial type inference #7582

Conversation

TomatorCZ commented Oct 7, 2023

jcouv commented Oct 16, 2023

jcouv Nov 2, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jcouv Nov 2, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jcouv Nov 2, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jcouv Nov 2, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jcouv Nov 2, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jaredpar Nov 3, 2023 • edited by jcouv Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TomatorCZ Feb 20, 2024 • edited Loading

Choose a reason for hiding this comment

jaredpar Nov 3, 2023 • edited by jcouv Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TomatorCZ commented Nov 3, 2023

TomatorCZ commented Nov 5, 2023

TomatorCZ commented Jan 15, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TomatorCZ commented Feb 3, 2024

Choose a reason for hiding this comment

TomatorCZ Apr 16, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jcouv Nov 2, 2023 •

edited

Loading

jcouv Nov 2, 2023 •

edited

Loading

jcouv Nov 2, 2023 •

edited

Loading

jcouv Nov 2, 2023 •

edited

Loading

jcouv Nov 2, 2023 •

edited

Loading

jaredpar Nov 3, 2023 •

edited by jcouv

Loading

TomatorCZ Feb 20, 2024 •

edited

Loading

jaredpar Nov 3, 2023 •

edited by jcouv

Loading

TomatorCZ Apr 16, 2024 •

edited

Loading