mirror of
https://github.com/golang/go
synced 2024-09-15 22:20:06 +00:00
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 <gri@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
This commit is contained in:
parent
9ed0d81fb5
commit
5d3476c3db
|
@ -2034,7 +2034,7 @@ interface{ int; string } // no specific types (intersection is empty)
|
|||
</pre>
|
||||
|
||||
<p>
|
||||
An interface <code>T</code> is called <i>structural</i> if one of the following
|
||||
An interface <code>T</code> has a <i>core type</i> if one of the following
|
||||
conditions is satisfied:
|
||||
</p>
|
||||
|
||||
|
@ -2051,8 +2051,11 @@ direction.
|
|||
</ol>
|
||||
|
||||
<p>
|
||||
A structural interface has a <i>structural type</i> which is, depending on the
|
||||
condition that is satisfied, either:
|
||||
All other interfaces don't have a core type.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The core type is, depending on the condition that is satisfied, either:
|
||||
</p>
|
||||
|
||||
<ol>
|
||||
|
@ -2067,7 +2070,7 @@ depending on the direction of the directional channels present.
|
|||
</ol>
|
||||
|
||||
<p>
|
||||
Examples of structural interfaces with their structural types:
|
||||
Examples of interfaces with core types:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
|
@ -2079,7 +2082,7 @@ interface{ ~[]*data; String() string } // []*data
|
|||
</pre>
|
||||
|
||||
<p>
|
||||
Examples of non-structural interfaces:
|
||||
Examples of interfaces whithout core types:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
|
@ -4497,19 +4500,21 @@ min(1.0, 2) // illegal: default type float64 (for 1.0) doesn't match default
|
|||
<h4 id="Constraint_type_inference">Constraint type inference</h3>
|
||||
|
||||
<!--
|
||||
The next paragraph needs to be updated for the new definition of structural type:
|
||||
The structural type of an interface is the single underlying type of its type set,
|
||||
The next paragraph needs to be updated for the new definition of core type:
|
||||
The core type of an interface is the single underlying type of its type set,
|
||||
if it exists. But for constraint type inference, if the type set consists of exactly
|
||||
one type, we want to use that one type (which may be a defined type, different from
|
||||
its underlying == structural type).
|
||||
its underlying == core type).
|
||||
-->
|
||||
|
||||
<p>
|
||||
Constraint type inference infers type arguments from already known
|
||||
type arguments by considering <a href="#Structure_of_interfaces">structural type constraints</a>:
|
||||
if the structural type <code>T</code> of a structural constraint is parameterized,
|
||||
<a href="#Type_unification">unifying</a> a known type argument with <code>T</code> 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 <code>P</code> has a constraint with a
|
||||
<a href="#Structure_of_interfaces">core type</a> <code>C</code>,
|
||||
<a href="#Type_unification">unifying</a> <code>P</code> with <code>C</code>
|
||||
may infer additional type arguments, either the type argument for <code>P</code>,
|
||||
or if that is already known, possibly the type arguments for type parameters
|
||||
used in <code>C</code>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
|
@ -4523,8 +4528,8 @@ For instance, consider the type parameter list with type parameters <code>List</
|
|||
|
||||
<p>
|
||||
Constraint type inference can deduce the type of <code>Elem</code> from the type argument
|
||||
for <code>List</code> because <code>Elem</code> is a type parameter in the structural constraint
|
||||
<code>~[]Elem</code> for <code>List</code>.
|
||||
for <code>List</code> because <code>Elem</code> is a type parameter in the core type
|
||||
<code>[]Elem</code> of <code>List</code>.
|
||||
If the type argument is <code>Bytes</code>:
|
||||
</p>
|
||||
|
||||
|
@ -4533,7 +4538,7 @@ type Bytes []byte
|
|||
</pre>
|
||||
|
||||
<p>
|
||||
unifying the underlying type of <code>Bytes</code> with the structural constraint means
|
||||
unifying the underlying type of <code>Bytes</code> with the core type means
|
||||
unifying <code>[]byte</code> with <code>[]Elem</code>. That unification succeeds and yields
|
||||
the <a href="#Type_unification">substitution map</a> entry
|
||||
<code>Elem</code> → <code>byte</code>.
|
||||
|
@ -4548,8 +4553,8 @@ substitution map <i>M</i>
|
|||
|
||||
<ol>
|
||||
<li>
|
||||
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.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
|
@ -4584,7 +4589,7 @@ the initial substitution map <i>M</i> contains the entry <code>A</code> &RightAr
|
|||
|
||||
<p>
|
||||
In the first phase, the type parameters <code>B</code> and <code>C</code> 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
|
||||
<code>B</code> → <code>[]C</code> and <code>C</code> → <code>*A</code>
|
||||
to <i>M</i>.
|
||||
|
||||
|
|
Loading…
Reference in a new issue