diff options
author | Robert Griesemer <gri@golang.org> | 2022-02-11 12:18:33 -0800 |
---|---|---|
committer | Robert Griesemer <gri@golang.org> | 2022-02-14 05:18:03 +0000 |
commit | badbc52d82b1f97861bf30457014fc9ea19dfcb2 (patch) | |
tree | 393f7aca1fb8353d71f52443eac80cb0f89f0165 | |
parent | 93b5309f0a239ad6a855d698c89731ff73570b47 (diff) | |
download | go-badbc52d82b1f97861bf30457014fc9ea19dfcb2.tar.gz go-badbc52d82b1f97861bf30457014fc9ea19dfcb2.zip |
spec: highlight missing prose for easier review, fixed a few sections
The (temporary) highlights will make it easier to review the spec
in formatted form as opposed to html text.
Added a missing rule about the use of adjusted core types for
constraint type inference.
Adjusted rule for invalid embedding of interface types.
Change-Id: Ie573068d2307b66c937e803c486724175415b9c6
Reviewed-on: https://go-review.googlesource.com/c/go/+/385535
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
-rw-r--r-- | doc/go_spec.html | 57 |
1 files changed, 36 insertions, 21 deletions
diff --git a/doc/go_spec.html b/doc/go_spec.html index b63aba5b16..bf8b5ed5bf 100644 --- a/doc/go_spec.html +++ b/doc/go_spec.html @@ -1,6 +1,6 @@ <!--{ "Title": "The Go Programming Language Specification - Go 1.18 Draft", - "Subtitle": "Version of Feb 11, 2022", + "Subtitle": "Version of Feb 14, 2022", "Path": "/ref/spec" }--> @@ -11,6 +11,11 @@ For the pre-Go1.18 specification without generics support see <a href="/doc/go1.17_spec.html">The Go Programming Language Specification</a>. </p> +<!-- TODO(gri) remove this before the final release --> +<p><b> +[For reviewers: Sections where we know of missing prose are marked like this. The markers will be removed before the release.] +</b></p> + <h2 id="Introduction">Introduction</h2> <p> @@ -1498,15 +1503,9 @@ type Floatish struct { } </pre> -<!-- TODO The rule below needs to be generalized to interface elements. - It should be factored out and generalized to other types - such as arrays and structs which are currently missing such a - rule. See also #5069. ---> - <p> -An interface type <code>T</code> may not embed itself -or any interface type that embeds <code>T</code>, recursively. +An interface type <code>T</code> may not embed any type element +that is, contains, or embeds <code>T</code>, recursively. </p> <pre> @@ -1522,6 +1521,11 @@ type Bad1 interface { type Bad2 interface { Bad1 } + +// illegal: Bad3 cannot embed a union containing Bad3 +type Bad3 interface { + ~int | ~string | Bad3 +} </pre> <h4 id="Implementing_an_interface">Implementing an interface</h4> @@ -1803,6 +1807,10 @@ interface{ <-chan int | chan<- int } // directional channels have dif <h3 id="Specific_types">Specific types</h3> +<p><b> +[The definition of specific types is not quite correct yet.] +</b></p> + <p> An interface specification that contains <a href="#Interface_types">type elements</a> defines a (possibly empty) set of <i>specific types</i>. @@ -3346,7 +3354,9 @@ f.p[i].x() <h3 id="Selectors">Selectors</h3> -<!-- This is missing rules for x of type parameter type. --> +<p><b> +[This section is missing rules for x.f where x's type is a type parameter and f is a field.] +</b></p> <p> For a <a href="#Primary_expressions">primary expression</a> <code>x</code> @@ -4557,14 +4567,6 @@ ensures that type inference does not depend on the order of the untyped argument <h4 id="Constraint_type_inference">Constraint type inference</h4> -<!-- - 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 == core type). ---> - <p> Constraint type inference infers type arguments by considering type constraints. If a type parameter <code>P</code> has a constraint with a @@ -4605,13 +4607,24 @@ first one. </p> <p> +Using the core type of a constraint may lose some information: In the (unlikely) case that +the constraint's type set contains a single <a href="#Type_definitions">defined type</a> +<code>N</code>, the corresponding core type is <code>N</code>'s underlying type rather than +<code>N</code> itself. In this case, constraint type inference may succeed but instantiation +will fail because the inferred type is not in the type set of the constraint. +Thus, constraint type inference uses the <i>adjusted core type</i> of +a constraint: if the type set contains a single type, use that type; otherwise use the +constraint's core type. +</p> + +<p> Generally, constraint type inference proceeds in two phases: Starting with a given substitution map <i>M</i> </p> <ol> <li> -For all type parameters with a core type, unify the type parameter with the core +For all type parameters with an adjusted core type, unify the type parameter with that type. If any unification fails, constraint type inference fails. </li> @@ -5369,7 +5382,7 @@ in any of these cases: </ul> <p> -Additionally, if <code>T</code> or </code><code>x's</code> type <code>V</code> are type +Additionally, if <code>T</code> or <code>x</code>'s type <code>V</code> are type parameters with <a href="#Specific_types">specific types</a>, <code>x</code> can also be converted to type <code>T</code> if one of the following conditions applies: </p> @@ -7317,7 +7330,9 @@ does not exist, <code>delete</code> is a no-op. <h3 id="Complex_numbers">Manipulating complex numbers</h3> -<!-- We don't support generic arguments for these operations yet. --> +<p><b> +[We don't support generic arguments for these built-ins for Go 1.18.] +</b></p> <p> Three functions assemble and disassemble complex numbers. |