code review 6699048: go spec: restrictions for index and slice expressions

go spec: restrictions for index and slice expressions

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 issue 4231.

[gri, 2012-10-15 23:24:29]

Hello r@golang.org, rsc@golang.org, iant@golang.org, ken@golang.org (cc:
golang-dev@googlegroups.com),

I'd like you to review this change to
https://code.google.com/p/go

[iant, 2012-10-15 23:41:58]

https://codereview.appspot.com/6699048/diff/4001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/6699048/diff/4001/doc/go_spec.html#newcode2504
doc/go_spec.html:2504: <li>if <code>x</code> is a <a
href="#Constant_expressions">constant expression</a> it must be in range
This doesn't work, because in general the compiler can not know the length of a
slice.  That is, the compiler can not whether a non-negative constant expression
is in range or not.

[gri, 2012-10-16 03:33:26]

https://codereview.appspot.com/6699048/diff/4001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/6699048/diff/4001/doc/go_spec.html#newcode2504
doc/go_spec.html:2504: <li>if <code>x</code> is a <a
href="#Constant_expressions">constant expression</a> it must be in range
On 2012/10/15 23:41:59, iant wrote:
> This doesn't work, because in general the compiler can not know the length of
a
> slice.  That is, the compiler can not whether a non-negative constant
expression
> is in range or not.

Sigh, of course not. I meant to separate the two (after all, I just coded this
in the type checker), but in the rush I missed that this is both for arrays and
slices. Update forthcoming.

[gri, 2012-10-16 04:51:36]

Hello r@golang.org, rsc@golang.org, iant@golang.org, ken@golang.org (cc:
golang-dev@googlegroups.com),

Please take another look.

[iant, 2012-10-16 13:04:48]

LGTM

What about slice expressions?

[gri, 2012-10-16 16:44:35]

Hello r@golang.org, rsc@golang.org, iant@golang.org, ken@golang.org (cc:
golang-dev@googlegroups.com),

Please take another look.

[rsc, 2012-10-16 19:04:20]

The semantics look good to me. Some wording nits.

"run time" is a noun, "run-time" is an adjective.
So "at run time" but "run-time error".

The spec does not have any mention of "compile time" before this CL. It talks
about programs being valid or invalid. Perhaps we should do the same here.

[gri, 2012-10-16 20:08:52]

Hello r@golang.org, rsc@golang.org, iant@golang.org, ken@golang.org (cc:
golang-dev@googlegroups.com),

Please take another look.

[r, 2012-10-16 22:01:25]

LGTM

although i share gri's nervousness.

we should probably have a serious talk about how much we want to specify what
the compiler catches vs. what the execution catches. consider

var x []int
x[0] = 1

or the even likelier

var m map[int]int
m[0] = 1

the current spec defines that the compiler cannot report this mistake. do we
want to be so prescriptive?

http://codereview.appspot.com/6699048/diff/22002/doc/go_spec.html
File doc/go_spec.html (right):

http://codereview.appspot.com/6699048/diff/22002/doc/go_spec.html#newcode2634
doc/go_spec.html:2634: A <a href="#Constant_expressions">constant</a> index must
not be negative, and if both indexes
s/indexes/indices/
i looked into it because i was unsure.  according to chanmbers, indexes is the
plural for the thing in the back of the book, indices for all other uses
including math.
there are a couple of other appearances that should be changed too, to be
consistent

[gri, 2012-10-16 23:23:18]

PTAL.

I wouldn't want to push it much farther in the spec.

We already have the notion of a constant and of a constant expressions and they
are important for the language as they define what can be used in types (array
lengths), const declarations, and untyped values. For instance, we already say
that array lengths must be constant and >= 0. It seems reasonable to restrict
other related constructs (like indices and make arguments).

There's much more that a good compiler could report at compile-time, and I think
perhaps it should. But I would be hesitant to make it part of the language spec.
As suggested by r, perhaps a serious discussion is warranted.

https://codereview.appspot.com/6699048/diff/22002/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/6699048/diff/22002/doc/go_spec.html#newcode2634
doc/go_spec.html:2634: A <a href="#Constant_expressions">constant</a> index must
not be negative, and if both indexes
On 2012/10/16 22:01:25, r wrote:
> s/indexes/indices/
> i looked into it because i was unsure.  according to chanmbers, indexes is the
> plural for the thing in the back of the book, indices for all other uses
> including math.
> there are a couple of other appearances that should be changed too, to be
> consistent

Done.

[r, 2012-10-17 03:36:34]

LGTM

[iant, 2012-10-17 17:12:21]

LGTM

https://codereview.appspot.com/6699048/diff/23002/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/6699048/diff/23002/doc/go_spec.html#newcode2531
doc/go_spec.html:2531: if the string <code>a</code> is constant, too</li>
s/constant, too/also constant/

[gri, 2012-10-17 18:08:55]

*** Submitted as http://code.google.com/p/go/source/detail?r=370bc7ed6c28 ***

go spec: restrictions for index and slice expressions

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 issue 4231.

R=r, rsc, iant, ken
CC=golang-dev
http://codereview.appspot.com/6699048

http://codereview.appspot.com/6699048/diff/23002/doc/go_spec.html
File doc/go_spec.html (right):

http://codereview.appspot.com/6699048/diff/23002/doc/go_spec.html#newcode2531
doc/go_spec.html:2531: if the string <code>a</code> is constant, too</li>
On 2012/10/17 17:12:21, iant wrote:
> s/constant, too/also constant/

Done.