- 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
Please note the slight rewording for append: The spec now
requires that append reuses the underlying array if it is
sufficiently large. Per majority sentiment.
This is technically a language change but the current
implementation always worked this way.
Fixes#5818.
Fixes#5180.
R=rsc, iant, r, ken, minux.ma, dan.kortschak, rogpeppe, go.peter.90
CC=golang-dev
https://golang.org/cl/14419054
Make the break example slightly more interesting
Update #5725
Effective Go will be updated in a separate CL.
R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/13368054
Remove "References" section.
Remove most articles and redirect to blog.golang.org.
Move /ref/spec and /ref/mem to /doc/spec and /doc/mem.
Remove duplicate links from the remaining
"Documents", "The Project", and "Help" pages.
Defer to the wiki for more links and community content.
Update command reference and mention cover tool.
Add "Pop-out" text to the front page.
Pick one of four videos at random to feature on the front page.
Fixes#2547.
Fixes#5561.
Fixes#6321.
R=r, dominik.honnef
CC=golang-dev
https://golang.org/cl/13724043
(Replacement for CL 11884043.)
1) Explain a[i] and a[i:j] where a is of type *A as
shortcut for (*a)[i] and (*a)[i:j], respectively.
2) Together with 1), because len() of nil slices is
well defined, there's no need to special case nil
operands anymore.
3) The result of indexing or slicing a constant string
is always a non-constant byte or string value.
4) The result of slicing an untyped string is a value
of type string.
5) If the operand of a valid slice a[i:j] is nil (i, j
must be 0 for it to be valid - this already follows
from the in-range rules), the result is a nil slice.
Fixes#4913.
Fixes#5951.
R=r, rsc, iant, ken
CC=golang-dev
https://golang.org/cl/12198043
CL submitted prematurely by mistake.
««« original CL description
spec: clarify index and selector expressions
1) Explain a[i] and a[i:j] where a is of type *A as
shortcut for (*a)[i] and (*a)[i:j], respectively.
2) Together with 1), because len() of nil slices is
well defined, there's no need to special case nil
operands anymore.
3) The result of indexing or slicing a constant string
is always a non-constant byte or string value.
4) The result of slicing an untyped string is a value
of type string.
5) If the operand of a valid slice a[i:j] is nil (i, j
must be 0 for it to be valid - this already follows
from the in-range rules), the result is a nil slice.
Fixes#4913.
Fixes#5951.
R=rsc, r, iant, ken
CC=golang-dev
https://golang.org/cl/11884043
»»»
R=r
CC=golang-dev
https://golang.org/cl/12170046
1) Explain a[i] and a[i:j] where a is of type *A as
shortcut for (*a)[i] and (*a)[i:j], respectively.
2) Together with 1), because len() of nil slices is
well defined, there's no need to special case nil
operands anymore.
3) The result of indexing or slicing a constant string
is always a non-constant byte or string value.
4) The result of slicing an untyped string is a value
of type string.
5) If the operand of a valid slice a[i:j] is nil (i, j
must be 0 for it to be valid - this already follows
from the in-range rules), the result is a nil slice.
Fixes#4913.
Fixes#5951.
R=rsc, r, iant, ken
CC=golang-dev
https://golang.org/cl/11884043
The notion of a named type is crucial for the definition
of type identity, assignability, definitions of methods.
Explicitly introduce the notion with an extra sentence.
Fixes#5682.
R=r, rsc, iant
CC=golang-dev
https://golang.org/cl/11055043
The existing compilers convert empty strings to empty
but non-nil byte and rune slices. The spec required
a nil byte and rune slice in those cases. That seems
an odd additional requirement. Adjust the spec to
match the reality.
Also, removed over-specification for conversions of
nil []byte and []rune: such nil slices already act
like empty slices and thus don't need extra language.
Added extra examples instead.
Fixes#5704.
R=rsc, r, iant
CC=golang-dev
https://golang.org/cl/10440045
Several old TODOs are either resolved now (e.g. when is a return
needed), or are from a time the language wasn't frozen (^ for uints
only). Consolidated the others.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/9599044
Although one may argue that they should be legal, gc (at least)
disallows byte order marks that are not the first code point
in the file. Added a sentence to the "Implementation restriction"
clause in the "Source code representation" section to document
this better.
Lifting this restriction (again - the rule has changed at least
twice already) would not break any existing programs, should
we later decide yet again to fiddle the rules about these little
fly specks.
R=golang-dev, dsymonds, gri
CC=golang-dev
https://golang.org/cl/8649043
Also:
- more consistenly use "xxx" statement rather than <code>xxx</code> statement
- fix/remove unnecessary links
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/7821050
Will help people find the rules by searching the spec by
having a comment saying "missing return";
"terminating statement" does not evoke the rule to the
uninitiated.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/7838044
