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>
Per a suggestion from mdempsky.
Both gc and gccgo consider a statement list as terminating if the
last _non_empty_ statement is terminating; i.e., trailing semis are
ok. Only gotype followed the current stricter rule in the spec.
This change adjusts the spec to match gc and gccgo behavior. In
support of this change, the spec has a matching rule for fallthrough,
which in valid positions may be followed by trailing semis as well.
For details and examples, see the issue below.
Fixes#14422.
Change-Id: Ie17c282e216fc40ecb54623445c17be111e17ade
Reviewed-on: https://go-review.googlesource.com/19981
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The () parentheses grouped wrongly. Removed them completely in
favor of separate 2- and 3-index slice alternatives which is
clearer.
Fixes#14477.
Change-Id: I0b7521ac912130d9ea8740b8793b3b88e2609418
Reviewed-on: https://go-review.googlesource.com/19853
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Slightly rephrased sentence to emphasize the contents of the
Unicode categories w/o repeating the full category name each
time.
Fixes#13414.
Change-Id: Icd32ff1547fa81e866c5937a631c3344bb6087c6
Reviewed-on: https://go-review.googlesource.com/18265
Reviewed-by: Rob Pike <r@golang.org>
The proper term is "untyped boolean".
Change-Id: Id871164190a03c64a8a8987b1ad5d8653a21d96e
Reviewed-on: https://go-review.googlesource.com/16135
Reviewed-by: Robert Griesemer <gri@golang.org>
The spec defines precise numeric constants which do not overflow.
Consequently, +/-Inf and NaN values were excluded. The case was not
clear for -0.0 but they are mostly of interest to determine the sign
of infinities which don't exist.
That said, the conversion rules explicitly say that T(x) (for a numeric
x and floating-point type T) is the value after rounding per IEEE-754.
The result is constant if x is constant. Rounding per IEEE-754 can
produce a -0.0 which we cannot represent as a constant.
Thus, the spec is inconsistent. Attempt to fix the inconsistency by
adjusting the rounding rule rather than letting -0.0 into the language.
For more details, see the issue below.
Open to discussion.
Fixes#12576.
Change-Id: Ibe3c676372ab16d9229f1f9daaf316f761e074ee
Reviewed-on: https://go-review.googlesource.com/14727
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The prose discussing composite literals referred to the composite
literal type with 'LiteralType', denoting the literal type's EBNF
production explicitly. Changed 'LiteralType' to 'literal type' to
remove the literal (no pun intended) connection and instead mean
the underlying type. Seems a simpler and more readable change
than referring to the underlying type everywhere explicitly.
Fixes#12717.
Change-Id: I225df95f9ece2664b19068525ea8bda5ca05a44a
Reviewed-on: https://go-review.googlesource.com/14851
Reviewed-by: Rob Pike <r@golang.org>
First step towards cleaning up the operator section - no language
changes. Specifically:
- Grouped arithmetic operations by types (integer, floating-point,
string), with corresponding h4 headings.
- Changed Operator precedence title from h3 to h4.
- Moved Integer Overflow section after integer operations and changed
its title from h3 to h4.
This puts things that belong together closer. No heading id's were
lost (in case of references from outside the spec).
Change-Id: I6b349ba8d86a6ae29b596beb297cc45c81e69399
Reviewed-on: https://go-review.googlesource.com/13143
Reviewed-by: Rob Pike <r@golang.org>
The spec didn't specify several aspects of expression switches:
- The switch expression is evaluated exactly once.
- Switch expressions evaluating to an untyped value are converted
to the respective default type before use.
- An (untyped) nil value is not permitted as expression switch
value. (We could permit it relatively easily, but gc doesn't,
and disallowing it is in symmetry with the rules for var decls
without explicit type and untyped initializer expressions.)
- The comparison x == t between each case expression x and
switch expression value t must be valid.
- (Some) duplicate constant case expressions are not permitted.
This change also clarifies the following issues:
4524: mult. equal int const switch case values should be illegal
-> spec issue fixed
6398: switch w/ no value uses bool rather than untyped bool
-> spec issue fixed
11578: allows duplicate switch cases -> go/types bug
11667: int overflow in switch expression -> go/types bug
11668: use of untyped nil in switch -> not a gc bug
Fixes#4524.
Fixes#6398.
Fixes#11668.
Change-Id: Iae4ab3e714575a5d11c92c9b8fbf027aa706b370
Reviewed-on: https://go-review.googlesource.com/12711
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
The document `doc/go_spec.html` uses "preceeding" instead of the word
"preceding" in one place.
Fixed another occurrence in `src/go/types/typexpr.go`.
Change-Id: Ic67f62026b5c9d002c5c5632299f14ecac8b02ae
Reviewed-on: https://go-review.googlesource.com/12354
Reviewed-by: Ian Lance Taylor <iant@golang.org>
No need to update the date; this is not a spec change.
Change-Id: I10a31234ed985c59e5d9b5328664a36661cef31e
Reviewed-on: https://go-review.googlesource.com/11531
Reviewed-by: Andrew Gerrand <adg@golang.org>
Suggested by mdempsky (see also issue #11161).
Change-Id: I1ab28febe19b7a092029499015073ce8749b4d99
Reviewed-on: https://go-review.googlesource.com/10960
Reviewed-by: Ian Lance Taylor <iant@golang.org>
- no "visible" change to spec but for updated date
- retired several outdated TODO items
- filed non-urgent issues 10953, 10954, 10955 for current TODOs
Change-Id: If87ad0fb546c6955a6d4b5801e06e5c7d5695ea2
Reviewed-on: https://go-review.googlesource.com/10382
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The spec explains later in the "Operator precedence" section that *
has a higher precedence than +, but the current production rule
requires that "1 + 2 * 3" be parsed as "(1 + 2) * 3", instead of the
intended "1 + (2 * 3)".
The new production rule better matches cmd/internal/gc/go.y's grammar:
expr:
uexpr
| expr LOROR expr
| expr LANDAND expr
| ...
Fixes#10151.
Change-Id: I13c9635d6ddf1263cafe7cc63e68f3e5779e24ba
Reviewed-on: https://go-review.googlesource.com/9163
Reviewed-by: Robert Griesemer <gri@golang.org>
to map element keys
Composite literals containing element values that are themselves composite
literals may leave away the element's literal types if they are identical
to the enclosing composite literal's element type.
(http://golang.org/ref/spec#Composite_literals)
When we made this change, we forgot to apply the analogous rule to map
literal keys. This change generalizes that rule. Added more examples,
including one showing the recursive application of the elision rules.
This is a fully backward-compatible language change. It was discussed
some time back.
Fixes#8589.
To be submitted once all compilers accept the extension.
Change-Id: I4d45b64b5970f0d5501572945d5a097e64a9458b
Reviewed-on: https://go-review.googlesource.com/2591
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Language clarification.
The existing rules for selector expressions imply
automatic dereferencing of pointers to struct fields.
They also implied automatic dereferencing of selectors
denoting methods. In almost all cases, such automatic
dereferencing does indeed take place for methods but the
reason is not the selector rules but the fact that method
sets include both methods with T and *T receivers; so for
a *T actual receiver, a method expecting a formal T
receiver, also accepts a *T (and the invocation or method
value expression is the reason for the auto-derefering).
However, the rules as stated so far implied that even in
case of a variable p of named pointer type P, a selector
expression p.f would always be shorthand for (*p).f. This
is true for field selectors f, but cannot be true for
method selectors since a named pointer type always has an
empty method set.
Named pointer types may never appear as anonymous field
types (and method receivers, for that matter), so this
only applies to variables declared of a named pointer
type. This is exceedingly rare and perhaps shouldn't be
permitted in the first place (but we cannot change that).
Amended the selector rules to make auto-deref of values
of named pointer types an exception to the general rules
and added corresponding examples with explanations.
Both gc and gccgo have a bug where they do auto-deref
pointers of named types in method selectors where they
should not:
See http://play.golang.org/p/c6VhjcIVdM , line 45.
Fixes#5769.
Fixes#8989.
LGTM=r, rsc
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/168790043
Not a language change.
This is simply documenting the status quo which permits
builtin function names to be parenthesized in calls; e.g.,
both
len(s)
and
(((len)))(s)
are accepted by all compilers and go/types.
Changed the grammar by merging the details of BuiltinCall
with ordinary Calls. Also renamed the Call production to
Arguments which more clearly identifies that part of the
grammar and also matches better with its counterpart on
the declaration side (Parameters).
The fact that the first argument can be a type (for builtins)
or cannot be a type (for regular function calls) is expressed
in the prose, no need to make the grammar more complicated.
Fixes#9001.
LGTM=iant, r, rsc
R=r, rsc, iant, ken, dave
CC=golang-codereviews
https://golang.org/cl/160570043
Per suggestion from rsc as a result of the dicussion of
(abandoned) CL 153110044.
Fixes#7192.
LGTM=r, rsc, iant
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/163050043
Not a language change.
Several inaccuracies were fixed:
1) A variable declaration may declare more than just one
variable.
2) Variable initialization follows the rules of assignments,
including n:1 assignments. The existing wording implied a 1:1
or n:n rule and generally was somewhat unspecific.
3) The rules for variable declarations with no types and
untyped initialization expressions had minor holes (issue 8088).
4) Clarified the special cases of assignments of untyped values
(we don't just have untyped constants, but also untyped bools,
e.g. from comparisons). The new wording is more direct.
To that end, introduced the notion of an untyped constant's
"default type" so that the same concept doesn't have to be
repeatedly introduced.
Fixes#8088.
LGTM=iant, r, rsc
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/142320043
The existing spec rules on package initialization were
contradictory: They specified that 1) dependent variables
are initialized in dependency order, and 2) independent
variables are initialized in declaration order. This 2nd
rule cannot be satisfied in general. For instance, for
var (
c = b + 2
a = 0
b = 1
)
because of its dependency on b, c must be initialized after b,
leading to the partial order b, c. Because a is independent of
b but is declared before b, we end up with the order: a, b, c.
But a is also independent of c and is declared after c, so the
order b, c, a should also be valid in contradiction to a, b, c.
The new rules are given in form of an algorithm which outlines
initialization order explicitly.
gccgo and go/types already follow these rules.
Fixes#8485.
LGTM=iant, r, rsc
R=r, rsc, iant, ken, gordon.klaus, adonovan
CC=golang-codereviews
https://golang.org/cl/142880043
