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:
-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:
-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 defaultConstraint 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 withT
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 parameterP
has a constraint with a +core typeC
, +unifyingP
withC
+may infer additional type arguments, either the type argument forP
, +or if that is already known, possibly the type arguments for type parameters +used inC
.@@ -4523,8 +4528,8 @@ For instance, consider the type parameter list with type parameters
List
Constraint type inference can deduce the type of
@@ -4533,7 +4538,7 @@ type Bytes []byteElem
from the type argument -forList
becauseElem
is a type parameter in the structural constraint -~[]Elem
forList
. +forList
becauseElem
is a type parameter in the core type +[]Elem
ofList
. If the type argument isBytes
:
-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
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.