From: Robert Griesemer Date: Tue, 8 Feb 2022 18:41:27 +0000 (-0800) Subject: spec: use "core type" rather than "structural type" X-Git-Tag: go1.18rc1~60 X-Git-Url: http://www.git.cypherpunks.su/?a=commitdiff_plain;h=5d3476c3dbc5e16b680e4b5ceab49c032b1b0a83;p=gostls13.git spec: use "core type" rather than "structural type" This change in terminology prevents potential confusion that migth be caused by associating "structural type" with "structural typing"; the two are not connected. Also, adjusted introductory paragraph of section on constraint type inference: type inference goes in both directions, from type parameter to core type and vice versa. The previous description was not quite accurate. Change-Id: If4ca300f525eea660f68486302619aa6ad5dbc2c Reviewed-on: https://go-review.googlesource.com/c/go/+/384238 Trust: Robert Griesemer Reviewed-by: Ian Lance Taylor --- diff --git a/doc/go_spec.html b/doc/go_spec.html index 358232ef91..a1800dcb5d 100644 --- a/doc/go_spec.html +++ b/doc/go_spec.html @@ -2034,7 +2034,7 @@ interface{ int; string } // no specific types (intersection is empty)

-An interface T is called structural if one of the following +An interface T has a core type if one of the following conditions is satisfied:

@@ -2051,8 +2051,11 @@ direction.

-A structural interface has a structural type which is, depending on the -condition that is satisfied, either: +All other interfaces don't have a core type. +

+ +

+The core type is, depending on the condition that is satisfied, either:

    @@ -2067,7 +2070,7 @@ depending on the direction of the directional channels present.

-Examples of structural interfaces with their structural types: +Examples of interfaces with core types: 

@@ -2079,7 +2082,7 @@ interface{ ~[]*data; String() string }    // []*data

-Examples of non-structural interfaces: +Examples of interfaces whithout core types: 

@@ -4497,19 +4500,21 @@ min(1.0, 2)    // illegal: default type float64 (for 1.0) doesn't match default
 
Constraint type inference

 
 
 
 

-Constraint type inference infers type arguments from already known
-type arguments by considering structural type constraints:
-if the structural type T of a structural constraint is parameterized,
-unifying a known type argument with T may
-infer type arguments for other type parameters used by the structural type.
+Constraint type inference infers type arguments by considering type constraints.
+If a type parameter P has a constraint with a
+core type C,
+unifying P with C
+may infer additional type arguments, either the type argument for P,
+or if that is already known, possibly the type arguments for type parameters
+used in C.
 

 
 

@@ -4523,8 +4528,8 @@ For instance, consider the type parameter list with type parameters List
 Constraint type inference can deduce the type of Elem from the type argument
-for List because Elem is a type parameter in the structural constraint
-~[]Elem for List.
+for List because Elem is a type parameter in the core type
+[]Elem of List.
 If the type argument is Bytes:
 

 
@@ -4533,7 +4538,7 @@ type Bytes []byte

-unifying the underlying type of Bytes with the structural constraint means +unifying the underlying type of Bytes with the core type means unifying []byte with []Elem. That unification succeeds and yields the substitution map entry Elem → byte. @@ -4548,8 +4553,8 @@ substitution map M

  1. -For all type parameters with a structural constraint, unify the type parameter with the structural -type of its constraint. If any unification fails, constraint type inference fails. +For all type parameters with a core type, unify the type parameter with the core +type. If any unification fails, constraint type inference fails.
  2. @@ -4584,7 +4589,7 @@ the initial substitution map M contains the entry A &RightAr

    In the first phase, the type parameters B and C are unified -with the structural type of their respective constraints. This adds the entries +with the core type of their respective constraints. This adds the entries B → []C and C → *A to M. @@ -5192,7 +5197,7 @@ as for non-constant x.

    Converting a constant to a type that is not a type parameter yields a typed constant. -Converting a constant to a type parameter yields a non-constant value of that type. +Converting a constant to a type parameter yields a non-constant value of that type.