GitLab

Replacing division-by-power-of-2 with right-shift is valid for
zero too.

R=gri
CC=golang-dev
https://golang.org/cl/7027049

A composite literal may be parenthesized when
used as operand for the unary operator &.

R=rsc, iant, r, ken
CC=golang-dev
https://golang.org/cl/6996053

Fixes #3814.

R=rsc, iant
CC=golang-dev
https://golang.org/cl/6920057

This is language change. It is a backward-compatible
change but for code that relies on a run-time panic
when calling delete on a nil map (unlikely).

Fixes #4253.

R=rsc, r, iant, ken, bradfitz, rogpeppe
CC=golang-dev
https://golang.org/cl/6909060

R=r, rsc, iant, ken
CC=golang-dev
https://golang.org/cl/6903048

Also, remove unnecessary whitespace.

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/6928045

We have been using all three terms "indices", "indexes",
and "index expressions" indiscriminatly for index values.
With this change, "index" refers to an index value,
"indices" is the plural of "index", and "index expression"
refers to an array, slice, or map indexed by an index: a[x].

R=r, rsc, iant, ken, mtj
CC=golang-dev
https://golang.org/cl/6912056

Fixes #4457.

R=rsc, iant, r, ken
CC=golang-dev
https://golang.org/cl/6862046

The spec didn't preclude invalid type assertions and
type switches, i.e., cases where a concrete type doesn't
implement the interface type in the assertion in the first
place. Both, the gc and gccgo compiler exclude these cases.
This is documenting the status quo.

Also:
- minor clean up of respective examples
- added sentence about default case in select statements

Fixes #4472.

R=rsc, iant, r, ken
CC=golang-dev
https://golang.org/cl/6869050

Also: fix an incorrect link.

Fixes #4479.
Fixes #4456.

R=rsc, iant, r, ken
CC=golang-dev
https://golang.org/cl/6868062

Also:
- 'for' statements with a range clause do not accept send-only
   channels
- '_, _ = range ch' is not equivalent to "_ = range ch" if ch
   is a channel (rewriting the latter to the former leads to
   an invalid range clause).

These clarifications document the status quo.

R=rsc, r, iant, ken
CC=golang-dev
https://golang.org/cl/6874053

Fixes #4450.

R=rsc, iant
CC=golang-dev
https://golang.org/cl/6845104

1) Built-ins are restricted like for expression statements.
   This documents the status quo.

2) Calls cannot be parenthesized. The spec is not clear. gccgo
   permits it already, gc doesn't. Be explicit in the spec.

 Fixes #4462.

R=rsc, iant, r, ken, lvd
CC=golang-dev
https://golang.org/cl/6861043

Since p.M is rejected (must call methods), use p.M(),
to keep the examples compiling.

Fixes #4441.

R=gri
CC=golang-dev
https://golang.org/cl/6854096

We have the notion of a PackageName, not package identifier.
As is, it could construed that imports that rename a package
don't have an "imported package identifier" but a local one.

R=r, rsc, iant, ken, dsymonds
CC=golang-dev
https://golang.org/cl/6858049

Fixes #4400.

R=r, mirtchovski
CC=golang-dev
https://golang.org/cl/6782084

R=golang-dev
CC=golang-dev
https://golang.org/cl/6818083

This is an attempt at making the interaction between
these three constructs clearer. Specifically:

- return statements terminate a function, execute deferred
  functions, return to the caller, and then execution
  continues after the call

- panic calls terminate a function, execute deferred
  functions, return to the caller, and then re-panic

- deferred functions are executed before a function _returns_
  to its caller

The hope is that with this change it becomes clear when a
deferred function is executed (when a function returns),
and when it is not (when a program exits).

R=r, rsc, iant, ken, iant
CC=golang-dev
https://golang.org/cl/6736071

Fixes #4324.

R=r
CC=golang-dev
https://golang.org/cl/6822062

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/6812060

Both gc and gccgo always checked this for constant
expressions but the spec only mentions run-time
exceptions.

This CL also requires that constant divisors
must not be zero in non-constant integer expressions:
This is consistent with the spirit of the most
recent changes and it is consistent with constant
expressions. We don't want to specify the effect for
non-integer expressions (f/0.0 where f is a float or
complex number) because there the result f/g is not
further specified if a non-constant g is 0.

R=r, rsc, iant, ken, andybalholm, iant
CC=golang-dev
https://golang.org/cl/6710045

This is a language change: Until now, the spec required run-
time panics for some of these errors. Note that gc and gccgo
implemented this inconsistently, and that both compilers already
reported compile-time errors in some cases. This change makes
make() behave along the same vein as index expressions.

This addresses the spec aspect of issue 4085.

R=r, rsc, iant, ken
CC=golang-dev
https://golang.org/cl/6725053

At the moment, gc and gccgo report compile-
time errors for certain constant indexes that
are out of bounds. The spec however requests
a run-time panic for out-of-bounds indexes
(http://tip.golang.org/ref/spec#Indexes).

Document the status quo.

Fixes #4231.

R=r, rsc, iant, ken
CC=golang-dev
https://golang.org/cl/6699048

Proposed new text to make matters clearer. The existing text was
unclear about the state of result parameters when panicking.

R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/6653047

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

Fixes #4142.

R=rsc, r, iant, ken, remyoudompheng
CC=golang-dev
https://golang.org/cl/6567062

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

- remove ambiguous 'it'
- use a lower-case PackageName in the example

R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/6552057

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

Happy Birthday UTF-8.

R=golang-dev, rsc, 0xjnml
CC=golang-dev
https://golang.org/cl/6506083

R=nigeltao
CC=golang-dev
https://golang.org/cl/6499075

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

R=r, rsc, iant, ken, iant
CC=golang-dev
https://golang.org/cl/6450150

Fixes #3852.

R=r, rsc, iant, ken
CC=golang-dev
https://golang.org/cl/6441102

R=golang-dev, dave, r
CC=golang-dev, remy
https://golang.org/cl/6378046