It's already there but only in the "for instance" and so not
clear enough: deferred functions run after
the result parameters are updated.
R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/6631058
Also: Be explicit what operator means with respect to conversion types.
The parenthesis requirement is a language change. At the moment,
literal function types in conversions that cannot possibly be
followed by a '(' don't need parentheses. For instance:
func(int)int(x) -> same as (func(int)int)(x)
func()()(x) -> same as (func())(x)
but:
func(int)(x) -> could be func(int)x {...}
Fixes#4109.
R=rsc, r, iant, ken, iant
CC=golang-dev
https://golang.org/cl/6584065
Also: Adjust prose in Conversions section
to be consistent.
This is a backward-compatible syntax change.
For a discussion see issue 2568.
Fixes#2568.
Fixes#4123.
R=golang-dev, r, iant, rsc
CC=golang-dev
https://golang.org/cl/6572049
Function and method calls are valid expression statements,
but calling certain built-in functions is not permitted.
Enumerate the built-ins.
Also: unsafe.Offsetof permits parenthesized selectors as
arguments.
This is simply documenting existing compiler behavior
(both gc and gccgo agree).
R=r, rsc, iant, ken
CC=golang-dev
https://golang.org/cl/6498138
Both gc and gccgo permit calls such as unsafe.Sizeof(42). The
spec only permits variable arguments. This is a (backward-compatible)
spec change reflecting the status quo. Seems preferrable over
restricting the compilers.
R=r, rsc, iant, ken
CC=golang-dev
https://golang.org/cl/6494140
Strings happen to be represented similarly to
byte slices internally, but they don't quite
behave like them: While strings can be indexed,
sliced, and have their len() taken like byte
slices, string elements are not addressable,
make() and cap() is not supported, range loops
operate differently, and they are immutable (and
thus behave like values rather then references).
Fixes#4018.
R=r, rsc, iant, ken
CC=golang-dev
https://golang.org/cl/6503116
The (and not) arguably sounds like it is trying to say something - and not what?.
Just an idea, won't be hurt if it gets rejected.
R=gri, dsymonds, r
CC=golang-dev
https://golang.org/cl/6498115
After further deliberation, let's back down to the Unicode proposal.
Ignoring aBOMinations anywhere means that things like
grep unsafe *.go
might fail because there's a BOM in the middle: unBOMsafe.
R=golang-dev, rsc, 0xjnml, gri, bradfitz
CC=golang-dev
https://golang.org/cl/6490091
No changes to the meaning, just clearer language and more
examples, including illegal rune and string literals.
In particular, "character literal" and "character constant"
are now called "rune literal" and "rune constant" and the
word "character" always refers to the source text, not
program values.
R=golang-dev, gri
CC=golang-dev
https://golang.org/cl/6448137
- point out difference between selectors and qualified identifiers
- differentiate between illegal selectors and run-time panics
- use "indirect" as opposed to "dereference" consistently
- add extra links
Fixes#3779.
R=r, rsc, iant, ken
CC=golang-dev
https://golang.org/cl/6326059
- receiving from a closed channel returns immediately
- in the ,ok form, the 2nd result is of type bool, not
just boolean (gc and ggcgo agree).
Per dsymonds' suggestion.
R=r, rsc, ken, iant, dsymonds
CC=golang-dev
https://golang.org/cl/6333057
They have been deleted from package unsafe.
Also delete their appearance in exp/types.
Fixes#3338.
R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/5847056
- Define what it means for two identifiers to be unique.
- The current spec is incorrect about exported
identifiers: for instance, it excluded fields
of non-exported types of exported variables
from being exported. It is easier to leave
the detailed specification away and let the
rest of the spec govern access of exported
identifiers.
- The current spec is incorrect about qualified
identifiers: It simply required that an identifier
be exported to be valid in a qualified identifier.
However, qualified identifiers can only access
exported identifiers declared in the package
block of the imported package.
Fixes#1551.
R=r, rsc, iant, ken
CC=golang-dev
https://golang.org/cl/5711043
- more idiomatic examples of pointer types
- show use of _ in examples of function types
- remove "legal:" qualification in examples
for consistency
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5711054
When we first wrote the method set definition, we had long
discussions about whether method sets applied to all types
or just named types, and we (or at least I) concluded that it
didn't matter: the two were equivalent points of view, because
the only way to introduce a new method was to write a method
function, which requires a named receiver type.
However, the addition of embedded types changed this.
Embedding can introduce a method without writing an explicit
method function, as in:
var x struct {
sync.Mutex
}
var px *struct {
sync.Mutex
}
var _, _ sync.Locker = &x, px
The edits in this CL make clear that both &x and px satisfy
sync.Locker. Today, gccgo already works this way; 6g does not.
R=golang-dev, gri, iant, r
CC=golang-dev
https://golang.org/cl/5702062
Or, depending on your point of view, make the
comparisons satisfy any surrounding boolean type.
Also, fix a few foo_bar -> fooBar in code fragments.
Fixes#2561.
R=golang-dev, r, bradfitz, gri, iant, kevlar
CC=golang-dev
https://golang.org/cl/5671096
Drop reference to "machine type." Specify that integer
overflow must be an error. Drop requirement that exponent
must be 128 bits--that's a lot. Clarify that floating point
expressions may be rounded, including intermediate values.
This is a reworking of https://golang.org/cl/5577068/ .
Fixes#2789.
R=r, rsc, r, gri, ken, ken, iant
CC=golang-dev, remyoudompheng
https://golang.org/cl/5655049
The paragraph describing the ellipses presents the horizontal ellipsis
in two different fonts and at least on my screen they look too different.
Switch to a consistent rendering.
Of small steps are great journeys undertaken.
R=golang-dev, rsc, dsymonds, gri
CC=golang-dev
https://golang.org/cl/5650055
Other wordings are possible but defining this as one
of the ways to proceed means we don't have to add
language about this to the description of select.
Fixes#2825.
R=golang-dev, gri, r
CC=golang-dev
https://golang.org/cl/5643062
