This is a spec correction, not a language change.
The implementations have behaved like this for years
(and there are tests to that effect), and elsewhere in
the spec true and false are defined to be untyped
boolean constants.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5477047
This has always been true, but we lost it from the spec
somewhere along the way, probably when we disallowed
the general 'pointer to anything sliceable' slice case.
R=gri
CC=golang-dev
https://golang.org/cl/5437121
The allowed conversions before and after are:
type Tstring string
type Tbyte []byte
type Trune []rune
string <-> string // ok
string <-> []byte // ok
string <-> []rune // ok
string <-> Tstring // ok
string <-> Tbyte // was illegal, now ok
string <-> Trune // was illegal, now ok
Tstring <-> string // ok
Tstring <-> []byte // ok
Tstring <-> []rune // ok
Tstring <-> Tstring // ok
Tstring <-> Tbyte // was illegal, now ok
Tstring <-> Trune // was illegal, now ok
Update spec, compiler, tests. Use in a few packages.
We agreed on this a few months ago but never implemented it.
Fixes#1707.
R=golang-dev, gri, r
CC=golang-dev
https://golang.org/cl/5421057
An experiment: allow structs to be copied even if they
contain unexported fields. This gives packages the
ability to return opaque values in their APIs, like reflect
does for reflect.Value but without the kludgy hacks reflect
resorts to.
In general, we trust programmers not to do silly things
like *x = *y on a package's struct pointers, just as we trust
programmers not to do unicode.Letter = unicode.Digit,
but packages that want a harder guarantee can introduce
an extra level of indirection, like in the changes to os.File
in this CL or by using an interface type.
All in one CL so that it can be rolled back more easily if
we decide this is a bad idea.
Originally discussed in March 2011.
https://groups.google.com/group/golang-dev/t/3f5d30938c7c45ef
R=golang-dev, adg, dvyukov, r, bradfitz, jan.mercl, gri
CC=golang-dev
https://golang.org/cl/5372095
This is true of the existing implementations, and I think
it is an important property to guarantee.
R=golang-dev, r, borman, r
CC=golang-dev
https://golang.org/cl/5321058
This is not a language change.
Added paragraphs specifying which conversions
yield results that are constants.
R=r, rsc, iant, ken
CC=golang-dev
https://golang.org/cl/4515176
This is (indirectly) a language change. Per e-mail discussion
on golang-dev.
Fixes#1943.
R=rsc, iant, r, ken
CC=golang-dev
https://golang.org/cl/4581058
- Added some additional examples.
- 6g appears to implement this semantics already.
Fixes#658.
R=rsc, r, iant, ken
CC=golang-dev
https://golang.org/cl/4538119
Note: This is not a spec change.
The spec was not clear on the result type of
constant shift expressions. Made it more
explicit and added additional examples.
Also: Remove paragraph on send expressions (they
are statements, now).
Fixes#1708.
R=rsc, r, iant, r
CC=golang-dev
https://golang.org/cl/4517074
This CL proposes some subtle language changes
in an attempt to clarify the semantics of range
clauses and simplify uses of maps.
- nil maps behave like empty maps; but attempting
to set a value in a nil map causes a run-time panic
- nil channels are never ready for communication;
sending or reading from a nil channel blocks forever
- if there is only one index iteration variable in a
range clause and len(range expression) would be a constant,
the range expression is not evaluated.
(was discrepancy with len/cap before)
- the notion of what is a constant expression len(x)
for (pointer to) arrays x has been generalized and
simplified (can still be syntactically decided)
(before: more restrictive syntactic rule that was not
consistently implemented)
Fixes#1713.
R=r, rsc, iant, ken2, r2, bradfitz, rog
CC=golang-dev
https://golang.org/cl/4444050
No language change.
- added a few examples with parentheses
- added a corresponding sentence to assignments
(this explicitly permits: (_) = 0, currently allowed by 6g,
gofmt, but marked as an error by gccgo).
R=rsc, r, iant
CC=golang-dev
https://golang.org/cl/4446071
The CL introduces inconsistencies with respect to
the use of parentheses/grouping of receive operations.
««« original CL description
spec: narrow syntax for expression and select statements
This is not a language change, it simply expresses the
accepted cases explicitly in the respective productions.
R=rsc, r, iant
CC=golang-dev
https://golang.org/cl/4428057
»»»
R=golang-dev, rsc1
CC=golang-dev
https://golang.org/cl/4444080
This is not a language change, it simply expresses the
accepted cases explicitly in the respective productions.
R=rsc, r, iant
CC=golang-dev
https://golang.org/cl/4428057
