Every few months we get a new error report claiming that there
is a typo in the spec related to this specific example. Clearly,
the fact that two types with the same identifier are identical
seems exceedingly obvious to readers; thus the example seems not
worth the trouble. Removing it.
For #9226.
For #22202.
For #22495.
For #23096.
For #23409.
There may be more.
Change-Id: I003ba79dc460ffb028a4ecb5f29efd60f2551912
Reviewed-on: https://go-review.googlesource.com/87417
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The spec refers to a map's key and element types; thus the respective
values are "keys" and "elements". Also, a map value is the value of
the entire map.
Similar fix for channels, where appropriate.
Fixes#23254.
Change-Id: I6f03ea6d86586c7b0b3e84f0c2e9446b8109fa53
Reviewed-on: https://go-review.googlesource.com/85999
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
A method expression is of the form T.m where T is a type and m
is a method of that type. The spec restricted T essentially to
a type name. Both cmd/compile and go/types accepted any type
syntactically, and a method expression was really just a form
of a selector expression x.f where x denotes a type.
This CL removes the spec syntax restriction from MethodExpr
to match the actual implementation. It also moves MethodExpr
from Operand to PrimaryExpr, because that's what it is.
It still keeps the separate notion of MethodExpr even though
it looks just like a selector expresion, since a MethodExpr
must start with a type rather than a value, and the spec's
syntax expresses this bit of semantics via distinct productions
(e.g., conversions look like calls but also must start with
a type).
Fixes#9060.
Change-Id: Idd84655b5b4f85d7ee53ebf749f73f0414a05f4a
Reviewed-on: https://go-review.googlesource.com/73233
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
https://golang.org/cl/71750 specifies iota values as indices,
thus making them independent from nested constant declarations.
This CL removes some of the comments in the examples that were
still referring to the old notion of iotas being incremented
and reset.
As an aside, please note that the spec still permits the use
of iota in a nested function (like before). Specifically, the
following cases are permitted by the spec (as before):
1) const _ = len([iota]int{})
2) const _ = unsafe.Sizeof(func(){ _ = iota })
For #15550.
Change-Id: I9e5fec75daf7b628b1e08d970512397e9c348923
Reviewed-on: https://go-review.googlesource.com/71912
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Issue #15550 is clearly an esoteric case but the spec was silent
about it and we had diverging implementations. By making `iota`
and index that is relative to the respective constant declaration,
nested const declarations won't affect outer values of `iota`.
cmd/compile and go/types already follow this semantics.
Fixes#15550.
Change-Id: If138189e3ea4373f8ba50ac6fb1d219b481f8698
Reviewed-on: https://go-review.googlesource.com/71750
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Fixes#22258.
Change-Id: I43e68f1cf3163e1a041ebff2734ff2cb7943f695
Reviewed-on: https://go-review.googlesource.com/71431
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Nowhere in the spec did we mention the import path for package
unsafe. Now we do.
Fixes#22308.
Change-Id: Ifd42c873188e898c597cdee4284e7a9d234a9282
Reviewed-on: https://go-review.googlesource.com/71373
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
When we introduced the distinction between "defined" and "alias" types
we retained the notion of a "named" type (any type with a name). The
predeclared types (which all have names) simply remained named types.
This CL clarifies the spec by stating excplicitly which predeclared
types are defined types (or at least "act" like defined types), and
which ones are alias types.
Fixes#21785.
Change-Id: Ia8ae133509eb5d738e6757b3442c9992355e3535
Reviewed-on: https://go-review.googlesource.com/64591
Reviewed-by: Russ Cox <rsc@golang.org>
The spec is not conclusive about whether a non-constant shift of
certain untyped constant left operands is valid when the shift
expression appears as an index in an index or slice expression,
or as a size in a `make` function call.
Despite identical spec rules in all these cases, cmd/compile accepts
make([]byte, 1.0 << s)
but pronounces an error for
a[1.0 << s]
(go/types accepts both).
This change clarifies the spec by explicitly stating that an
untyped constant left operand in a non-constant shift (1.0 in
the above examples) will be given type `int` in these contexts.
A separate issue #21693 addresses the cmd/compile bug.
Fixes#14844.
Change-Id: I4b52125e487a607fae377fcbed55463cdce9836c
Reviewed-on: https://go-review.googlesource.com/60230
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The last sentence in the section on slice expressions could be read
as if it might apply to strings. Changed the sentence a bit to
emphasize its applicability to slices only. See also the issue for
more background.
Fixes#19220.
Change-Id: I8551f34230e4ed93f951e7b871cc81f54a5874a9
Reviewed-on: https://go-review.googlesource.com/59890
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Throughout the spec we use the notion of a constant x being
representable by a value of type T. While intuitively clear,
at least for floating-point and complex constants types, the
concept was not well-defined. In the section on Conversions
there was an extra rule for floating-point types only and it
missed the case of floating-point values overflowing to an
infinity after rounding.
Since the concept is important to Go, and a compiler most
certainly will have a function to test "representability",
it seems warranted to define the term explicitly in the spec.
This change introduces a new entry "Representability" under
the section on "Properties of types and values", and defines
the term explicitly, together with examples.
The phrase used is "representable by" rather than "representable as"
because the former use is prevalent in the spec.
Additionally, it clarifies that a floating-point constant
that overflows to an infinity after rounding is never
representable by a value of a floating-point type, even though
infinities are valid values of IEEE floating point types.
This is required because there are not infinite value constants
in the language (like there is also no -0.0) and representability
also matters for constant conversions. This is not a language
change, and type-checkers have been following this rule before.
The change also introduces links throughout the spec to the new
section as appropriate and removes duplicate text and examples
elsewhere (Constants and Conversions sections), leading to
simplifications in the relevant paragraphs.
Fixes#15389.
Change-Id: I8be0e071552df0f18998ef4c5ef521f64ffe8c44
Reviewed-on: https://go-review.googlesource.com/57530
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The enumeration of numeric types missed the complex types.
Clarify by removing the explicit enumeration and referring
to numeric types instead.
Fixes#21579.
Change-Id: If36c2421f8501eeec82a07f442ac2e16a35927ba
Reviewed-on: https://go-review.googlesource.com/58491
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
The old wording seemed to imply that nil is a kind of type.
Slightly reworded for clarity.
Fixes#21580.
Change-Id: I29898bf0125a10cb8dbb5c7e63ec5399ebc590ca
Reviewed-on: https://go-review.googlesource.com/58490
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Rob Pike <r@golang.org>
The old comment for the example
type PtrMutex *Mutex
talked about the method set of the base type of PtrMutex.
It's more direct and clearer to talk about the underlying
type of PtrMutex for this specific example.
Also removed link inside pre-formatted region of text.
Fixes#20900.
Change-Id: Ie37340e53670e34ebe13e780ba8ccb1bba67795c
Reviewed-on: https://go-review.googlesource.com/55070
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
For non-constant shifts with an untyped constant shift count, the
spec only said that it must "be converted to unsigned integer type".
go/types accepts any (arbitrarily large) integer value. Both cmd/compile
and gccgo require that the shift count be representable as a uint value
in that case (if the shift count is typed, it may be any unsigned integer
type).
This change adjusts the spec to state what the compilers have been doing
all along. The new wording matches similar rules elsewhere (e.g., for
untyped array and slice indices). Also, while technically this is a
restriction (we could permit arbitrarily large shift counts), in practice
this is irrelevant.
Fixes#14822.
Change-Id: Ia75834c67483cf761c10025c8df758f225ef67c2
Reviewed-on: https://go-review.googlesource.com/45072
Reviewed-by: Ian Lance Taylor <iant@golang.org>
A pointer type of underlying type unsafe.Pointer can be used in
unsafe conversions. Document unfortunate status quo.
Fixes#19306.
Change-Id: I28172508a200561f8df366bbf2c2807ef3b48c97
Reviewed-on: https://go-review.googlesource.com/42132
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Added a paragraph and examples explaining when an implementation
may use fused floating-point operations (such as FMA) and how to
prevent operation fusion.
For #17895.
Change-Id: I64c9559fc1097e597525caca420cfa7032d67014
Reviewed-on: https://go-review.googlesource.com/40391
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The section on map literals mentions constant map keys but doesn't say
what happens for equal non-constant map keys - that is covered in the
section on evaluation order. Added respective link for clarity.
Fixes#19689.
Change-Id: If9a5368ba02e8250d4bb0a1d60d0de26a1f37bbb
Reviewed-on: https://go-review.googlesource.com/38598
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The (original) section on "Operators and Delimiters" introduced
superfluous terminology ("delimiter", "special token") which
didn't matter and was used inconsistently.
Removed any mention of "delimiter" or "special token" and now
simply group the special character tokens into "operators"
(clearly defined via links), and "punctuation" (everything else).
Fixes#19450.
Change-Id: Ife31b24b95167ace096f93ed180b7eae41c66808
Reviewed-on: https://go-review.googlesource.com/38073
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Rob Pike <r@golang.org>
To avoid confusion caused by the term "named type" (which now just
means a type with a name, but formerly meant a type declared with
a non-alias type declaration), a type declaration now comes in two
forms: alias declarations and type definitions. Both declare a type
name, but type definitions also define new types.
Replace the use of "named type" with "defined type" elsewhere in
the spec.
For #18130.
Change-Id: I49f5ddacefce90354eb65ee5fbf10ba737221995
Reviewed-on: https://go-review.googlesource.com/36213
Reviewed-by: Rob Pike <r@golang.org>
First steps towards defining type aliases in the spec.
This is a nomenclature clarification, not a language change.
The spec used all three terms 'embedded type', 'anonymous field',
and 'embedded field'. Users where using the terms inconsistently.
The notion of an 'anonymous' field was always misleading since they
always had a de-facto name. With type aliases that name becomes even
more important because we may have different names for the same type.
Use the term 'embedded field' consistently and remove competing
terminology.
For #18130.
Change-Id: I2083bbc85788cab0b2e2cb1ff58b2f979491f001
Reviewed-on: https://go-review.googlesource.com/35108
Reviewed-by: Alan Donovan <adonovan@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
This matches what we already do for switch statements and makes
this large section more visibly organized. No other changes besides
introducing the titles.
Fixes#4486.
Change-Id: I73f274e4fdd27c6cfeaed79090b4553e57a9c479
Reviewed-on: https://go-review.googlesource.com/33410
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
- organize examples better
- add an example illustrating behavior if element type is a named pointer type
- both compilers and go/types (per https://go-review.googlesource.com/33358)
follow this now
See the issue for detailed discussion.
Fixes#17954.
Change-Id: I8d90507ff2347d9493813f75b73233819880d2b4
Reviewed-on: https://go-review.googlesource.com/33361
Reviewed-by: Rob Pike <r@golang.org>
A 16bit binary exponent permits a constant range covering roughly the range
from 7e-9865 to 7e9863 which is more than enough for any practical and
hypothetical constant arithmetic.
Furthermore, until recently cmd/compile could not handle very large exponents
correctly anyway; i.e., the chance that any real programs (but for tests that
explore corner cases) are affected are close to zero.
Finally, restricting the minimum supported range significantly reduces the
implementation complexity in an area that hardly matters in reality for new
or alternative spec-compliant implementations that don't or cannot rely on
pre-existing arbitratry precision arithmetic packages that support a 32bit
exponent range.
This is technically a language change but for the reasons mentioned above
this is unlikely to affect any real programs, and certainly not programs
compiled with the gc or gccgo compilers as they currently support up to
32bit exponents.
Fixes#13572.
Change-Id: I970f919c57fc82c0175844364cf48ea335f17d39
Reviewed-on: https://go-review.googlesource.com/17711
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
This simply documents the status quo accepted by cmd/compile, gccgo,
and go/types. The new language matches the language used for indices
of index expressions for arrays and slices.
Fixes#16679.
Change-Id: I65447889fbda9d222f2a9e6c10334d1b38c555f0
Reviewed-on: https://go-review.googlesource.com/30474
Reviewed-by: Rob Pike <r@golang.org>
This is a backwards-compatible language change.
Per the proposal (#16085), the rules for conversions are relaxed
such that struct tags in any of the structs involved in the conversion
are ignored (recursively).
Because this is loosening the existing rules, code that compiled so
far will continue to compile.
For #16085.
Fixes#6858.
Change-Id: I0feef651582db5f23046a2331fc3f179ae577c45
Reviewed-on: https://go-review.googlesource.com/24190
Reviewed-by: Russ Cox <rsc@golang.org>
See the issue below for details.
Fixes#16794.
Change-Id: I7e338089fd80ddcb634fa80bfc658dee2772361c
Reviewed-on: https://go-review.googlesource.com/27356
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The enumerations didn't include the syntactic form where the lhs is
full variable declaration with type specification, as in:
var x, ok T = ...
Fixes#15782.
Change-Id: I0f7bafc37dc9dcf62cdb0894a0d157074ccd4b3e
Reviewed-on: https://go-review.googlesource.com/27670
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
The changes match the existing compilers, and assume an adjusted
spec (per issue #16794).
Fixes#15686.
Change-Id: I72677ce75888c41a8f3c2963117a2f2d5501c42b
Reviewed-on: https://go-review.googlesource.com/27290
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Both compilers and also go/types don't permit duplicate types in
type switches; i.e., this spec change is documenting a status quo
that has existed for some time.
Furthermore, duplicate nils are not accepted by gccgo or go/types;
and more recently started causing a compiler error in gc. Permitting
them is inconsistent with the existing status quo.
Rather than making it an implementation restriction (as we have for
expression switches), this is a hard requirement since it was enforced
from the beginning (except for duplicate nils); it is also a well
specified requirement that does not pose a significant burden for
an implementation.
Fixes#15896.
Change-Id: If12db5bafa87598b323ea84418cb05421e657dd8
Reviewed-on: https://go-review.googlesource.com/23584
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Note that the spec already makes that point with a comment in the very first
example for struct field tags. This change is simply stating this explicitly
in the actual spec prose.
- gccgo and go/types already follow this rule
- the current reflect package API doesn't distinguish between absent tags
and empty tags (i.e., there is no discoverable difference)
Fixes#15412.
Change-Id: I92f9c283064137b4c8651630cee0343720717a02
Reviewed-on: https://go-review.googlesource.com/22391
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
