From e50f0f372b07149e9cf16b8fec80d2d72efe2a87 Mon Sep 17 00:00:00 2001 From: Robert Griesemer Date: Thu, 10 Feb 2022 20:10:33 -0800 Subject: [PATCH] spec: describe processing of function arguments for type inference more precisely The outcome of type inference depends critically on when function argument type inference stops processing arguments. Describe this and explain an example with some detail. Also: In the section on the built-in function delete, refer to the value rather than the type of the second argument, as it may be an untyped constant. Change-Id: Ice7fbb33f985afe082380b8d37eaf763238a3818 Reviewed-on: https://go-review.googlesource.com/c/go/+/385034 Trust: Robert Griesemer Reviewed-by: Ian Lance Taylor --- doc/go_spec.html | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/doc/go_spec.html b/doc/go_spec.html index 49533b067d..061f933ae8 100644 --- a/doc/go_spec.html +++ b/doc/go_spec.html @@ -4514,6 +4514,12 @@ Each list is processed in a separate phase: +

+While unification is successful, processing of each list continues until all list elements +are considered, even if all type arguments are inferred before the last list element has +been processed. +

+

Example:

@@ -4527,6 +4533,13 @@ min(1.0, 2.0) // T is float64, inferred from default type for 1.0 and matches d min(1.0, 2) // illegal: default type float64 (for 1.0) doesn't match default type int (for 2) +

+In the example min(1.0, 2), processing the function argument 1.0 +yields the substitution map entry T → float64. Because +processing continues until all untyped arguments are considered, an error is reported. This +ensures that type inference does not depend on the order of the untyped arguments. +

+

Constraint type inference