From 4f51db24f4b80770000b28073a8bde57d021b4e4 Mon Sep 17 00:00:00 2001 From: Robert Griesemer Date: Tue, 30 May 2023 15:13:53 -0700 Subject: [PATCH] doc/go1.21: document type inference changes For #39661. For #41176. For #51593. For #52397. For #57192. For #58645. For #58650. For #58671. For #59338. For #59750. For #60353. Change-Id: Ib731c9f2879beb541f44cb10e40c36a8677d3ad4 Reviewed-on: https://go-review.googlesource.com/c/go/+/499282 TryBot-Bypass: Robert Griesemer Reviewed-by: Ian Lance Taylor Reviewed-by: Robert Griesemer --- doc/go1.21.html | 53 +++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 51 insertions(+), 2 deletions(-) diff --git a/doc/go1.21.html b/doc/go1.21.html index 3f7a73947f..97ee457a32 100644 --- a/doc/go1.21.html +++ b/doc/go1.21.html @@ -70,8 +70,57 @@ Do not send CLs removing the interior tags from such phrases. spec in past releases. The new rule provides an unambiguous definition.

-

- TODO: https://go.dev/issue/59338: infer type arguments from assignments of generic functions (reverse type inference) +

+ Multiple improvements that increase the power and precision of type inference have been made. +

+
    +
  • + A (possibly partially instantiated generic) function may now be called with arguments that are + themselves (possibly partially instantiated) generic functions. + The compiler will attempt to infer the missing type arguments of the callee (as before) and, + for each argument that is a generic function that is not fully instantiated, + its missing type arguments (new). + Typical use cases are calls to generic functions operating on containers + (such as slices.IndexFunc) where a function argument + may also be generic, and where the type argument of the called function and its arguments + are inferred from the container type. + More generally, a generic function may now be used without explicit instantiation when + it is assigned to a variable or returned as a result value if the type arguments can + be inferred from the assignment. +
    • +
  • + Type inference now also considers methods when a value is assigned to an interface: + type arguments for type parameters used in method signatures may be inferred from + the corresponding parameter types of matching methods. +
    • +
  • + Similarly, since a type argument must implement all the methods of its corresponding constraint, + the methods of the type argument and constraint are matched which may lead to the inference of + additional type arguments. +
    • +
  • + If multiple untyped constant arguments of different kinds (such as an untyped int and + an untyped floating-point constant) are passed to parameters with the same (not otherwise + specified) type parameter type, instead of an error, now type inference determines the + type using the same approach as an operator with untyped constant operands. + This change brings the types inferred from untyped constant arguments in line with the + types of constant expressions. +
    • +
  • + Type inference is now precise when matching corresponding types in assignments: + component types (such as the the elements of slices, or the parameter types in function signatures) + must be identical (given suitable type arguments) to match, otherwise inference fails. + This change produces more accurate error messages: + where in the past type inference may have succeeded incorrectly and lead to an invalid assignment, + the compiler now reports an inference error if two types can't possibly match. +
    • +
+ +

+ More generally, the description of + type inference + in the language spec has been clarified. + Together, all these changes make type inference more powerful and inference failures less surprising.

-- 2.50.0