mirror of https://github.com/golang/go.git
46f352de2d
Specific types were introduced to explain rules for operands of type parameter type. Specific types are really an implementation mechanism to represent (possibly infinite) type sets in the machine; they are not needed in the specification. A specific type is either standing for a single named or unnamed type, or it is the underlying (unnamed) type of an infinite set of types. Each rule that applies to a type T of the set of specific types must also apply to all types T' in the type set for which T is a representative of. Thus, in the spec we can simply refer to the type set directly, infinite or not. Rather then excluding operands with empty type sets in each instance, leave unspecified what happens when such an operand is used. Instead give an implementation some leeway with an implementation restriction. (The implementation restriction also needs to be formulated for types, such as in conversions, which technically are not "operands". Left for another CL.) Minor: Remove the two uses of the word "concrete" to refer to non- interface types; instead just say "non-interface type" for clarity. Change-Id: I67ac89a640c995369c9d421a03820a0c0435835a Reviewed-on: https://go-review.googlesource.com/c/go/+/390694 Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> |
||
|---|---|---|
| .. | ||
| asm.html | ||
| go1.17_spec.html | ||
| go1.19.html | ||
| go_mem.html | ||
| go_spec.html | ||