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
The proposed text in the last CL had a comma that was missing from the submitted spec.
LGTM=gri
R=gri
CC=golang-codereviews
https://golang.org/cl/150720043
Preparation for fixing issue 5769 (method selectors
do not auto-dereference): The actual fix may require
some cleanups in all these sections, and syntactically,
method expressions and method values are selector
expressions. Moving them next to each other so that
it's easy to see the actual changes (next CL).
No content changes besides the section moves.
LGTM=iant, rsc
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/132300043
Technically a language change, this cleanup is a completely
backward compatible change that brings the boolean results
of comma-ok expressions in line with the boolean results of
comparisons: they are now all untyped booleans.
The implementation effort should be minimal (less than a
handfull lines of code, depending how well factored the
implementation of comma-ok expressions is).
Fixes#8189.
LGTM=iant, r, rsc
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/112320045
golang.org now serves HTTPS with a valid cert, so it's reasonable
that users should click through to the HTTPS versions of *.golang.org
and other known sites.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/112650043
This is a fully backward-compatible language change.
There are not a lot of cases in the std library, but
there are some. Arguably this makes the syntax a bit
more regular - any trailing index variable that is _
can be left away, and there's some analogy to type
switches where the temporary can be left away.
Implementation-wise the change should be trivial as
it can be done completely syntactically. For instance,
the respective change in go/parser is a dozen lines
(see https://golang.org/cl/112970044 ).
Fixes#6102.
LGTM=iant, r, rsc
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/104680043
This CL removes the special syntax for method receivers and
makes it just like other parameters. Instead, the crucial
receiver-specific rules (exactly one receiver, receiver type
must be of the form T or *T) are specified verbally instead
of syntactically.
This is a fully backward-compatible (and minor) syntax
relaxation. As a result, the following syntactic restrictions
(which are completely irrelevant) and which were only in place
for receivers are removed:
a) receiver types cannot be parenthesized
b) receiver parameter lists cannot have a trailing comma
The result of this CL is a simplication of the spec and the
implementation, with no impact on existing (or future) code.
Noteworthy:
- gc already permits a trailing comma at the end of a receiver
declaration:
func (recv T,) m() {}
This is technically a bug with the current spec; this CL will
legalize this notation.
- gccgo produces a misleading error when a trailing comma is used:
error: method has multiple receivers
(even though there's only one receiver)
- Compilers and type-checkers won't need to report errors anymore
if receiver types are parenthesized.
Fixes#4496.
LGTM=iant, rsc
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/101500044
Also made it extra clear for goto statements (even though label scopes
are already limited to the function defining a label).
Fixes#8040.
LGTM=r, rsc
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/99550043
The spec was unclear about whether blank methods should be
permitted in interface types. gccgo permits at most one, gc
crashes if there are more than one, go/types permits at most
one.
Discussion:
Since method sets of non-interface types never contain methods
with blank names (blank methods are never declared), it is impossible
to satisfy an interface with a blank method.
It is possible to declare variables of assignable interface types
(but not necessarily identical types) containing blank methods, and
assign those variables to each other, but the values of those
variables can only be nil.
There appear to be two "reasonable" alternatives:
1) Permit at most one blank method (since method names must be unique),
and consider it part of the interface. This is what appears to happen
now, with corner-case bugs. Such interfaces can never be implemented.
2) Permit arbitrary many blank methods but ignore them. This appears
to be closer to the handling of blank identifiers in declarations.
However, an interface type literal is not a declaration (it's a type
literal). Also, for struct types, blank identifiers are not ignored;
so the analogy with declarations is flawed.
Both these alternatives don't seem to add any benefit and are likely
(if only slightly) more complicated to explain and implement than
disallowing blank methods in interfaces altogether.
Fixes#6604.
LGTM=r, rsc, iant
R=r, rsc, ken, iant
CC=golang-codereviews
https://golang.org/cl/99410046
The spec did not specify the order in which
init() functions are called. Specify that
they are called in source order since we have
now also specified the initialization order
of independent variables.
While technically a language change, no
existing code could have relied on this,
so this should not break anything.
Per suggestion from rsc.
LGTM=r, iant
R=rsc, iant, r, ken
CC=golang-codereviews
https://golang.org/cl/98420046
- split description of package initialization and
program execution
- better grouping of concerns in section on package
initialization
- more explicit definition of what constitues a
dependency
- removed language about constant dependencies -
they are computed at compile-time and not
initialized at run-time
- clarified that independent variables are initialized
in declaration order (rather than reference order)
Note that the last clarification is what distinguishes
gc and gccgo at the moment: gc uses reference order
(i.e., order in which variables are referenced in
initialization expressions), while gccgo uses declaration
order for independent variables.
Not a language change. But adopting this CL will
clarify what constitutes a dependency.
Fixes#6703.
LGTM=adonovan, r, iant, rsc
R=r, rsc, iant, ken, adonovan
CC=golang-codereviews
https://golang.org/cl/99020043
- use previously defined terms (with links) throughout
- specify evaluation order more precisely (in particular,
the evaluation time of rhs expressions in receive cases
was not specified)
- added extra example case
Not a language change.
Description matches observed behavior of code compiled
with gc and gccgo.
Fixes#7669.
LGTM=iant, r, rsc
R=r, rsc, iant, ken, josharian
CC=golang-codereviews
https://golang.org/cl/91230043
- A channel may be used between any number of goroutines,
not just two.
- Replace "passing a value" (which is not further defined)
by "sending and receiving a value".
- Made syntax production more symmetric.
- Talk about unbuffered channels before buffered channels.
- Clarify what the comma,ok receive values mean (issue 7785).
Not a language change.
Fixes#7785.
LGTM=rsc, r, iant
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/94030045
This is a clarification of what happens already.
Not a language change.
Fixes#7137.
LGTM=iant, r, rsc
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/96000044
If the underlying type of a type T is a boolean, numeric,
or string type, then T is also a boolean, numeric, or
string type, respectively.
Not a language change.
Fixes#7551.
LGTM=iant, rsc, robert.hencke, r
R=r, rsc, iant, ken, robert.hencke
CC=golang-codereviews
https://golang.org/cl/100130044
Currently tip.golang.org leads to golang.org and
local godoc also leads to golang.org (when you don't have internet connectivity).
LGTM=crawshaw
R=golang-codereviews, crawshaw
CC=golang-codereviews
https://golang.org/cl/100200043
This documents the status quo for most implementations,
with one exception: gc generates a run-time error for
constant but out-of-range indices when slicing a constant
string. See issue 7200 for a detailed discussion.
LGTM=r
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/72160044
The underlying type of the predeclared type error is not itself,
but the interface it is defined as.
Fixes#7444.
LGTM=r, rsc
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/71790044
This documents the implemented behavior of both
gc and gccgo as an implementation restriction.
NOT A LANGUAGE CHANGE.
Fixes#5425.
LGTM=rsc, r, iant
R=r, iant, rsc, ken
CC=golang-codereviews
https://golang.org/cl/71430043
gccgo considers built-in function calls returning a constant not as function call (issue 7386)
go/types considers any call (regular or built-in) as a function call
The wording and examples clarify that only "function calls" that are issued
at run-time (and thus do not result in a constant result) are considered
function calls in this case.
gc is inconsistent (issue 7385)
gccgo already interprets the spec accordingly and issue 7386 is moot.
go/types considers all calls (constant or not) as function calls (issue 7457).
Fixes#7387.
Fixes#7386.
LGTM=r, rsc, iant
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/66860046
An absent condition/tag in for and switch statements is equivalent
to the predeclared constant true; not simply the expression true
(which might lead to a locally defined true).
Not a language change.
Fixes#7404.
LGTM=iant, r
R=r, iant, rsc, ken
CC=golang-codereviews
https://golang.org/cl/68150046
No change to the meaning, just bad writing found by
Doug McIlroy.
Let's start the new year off with a bang.
R=golang-codereviews, bradfitz, dave
CC=golang-codereviews
https://golang.org/cl/47110044
