code review 6725053: go spec: define make() restrictions as for index expressions

go spec: define make() restrictions as for index expressions

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.

[gri, 2012-10-17 18:46:04]

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-17 18:48:23]

LGTM

[r, 2012-10-17 22:17:32]

https://codereview.appspot.com/6725053/diff/1002/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/6725053/diff/1002/doc/go_spec.html#newcode4928
doc/go_spec.html:4928: a <a href="#Run_time_panics">run-time panic</a> occurs.
this is a good example of what i was talking about yesterday. adding language
about run time prevents the compiler from complaining about
make([]byte, 10, 0)

the previous sentence has the vague "must hold". i think it should be clear the
the compiler might complain. for one thing, this is an easy error to make,
forgetting the order of len and cap. i've made it myself.

i'm starting to think the spec should shy away from saying when the error is
detected, that it should be the implementer's decision between compiler and
run-time, if even both exist.

maybe something as simple as this is all you need:

It is an error if n > m or if either value is negative.

this gives the compiler, if there is one, the freedom to reject the program, but
guarantees that if not, the run-time implementation will catch it.

[gri, 2012-10-18 18:36:12]

You have a valid concern and I voiced the same worry before.

I have convinced myself that what we have so far is still ok: In Go, we have an
explicit and precisely defined notion of what a constant is, and constants are
exact. Thus, arguably, constants are a part of the type system (in fact, they
mix with "pure" types with array declarations, for instance). Both the type
system and our "constant system" is decidable (well, mostly), by design. We rely
on the compiler checking our types for correctness. It can't do so everywhere,
which is why we have run-time type assertions. I think the same is true for
constants. The compiler does check constant expressions, and it can check
several things with index and slice expressions. It should do the same here.

- gri

https://codereview.appspot.com/6725053/diff/1002/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/6725053/diff/1002/doc/go_spec.html#newcode4928
doc/go_spec.html:4928: a <a href="#Run_time_panics">run-time panic</a> occurs.
On 2012/10/17 22:17:32, r wrote:
> this is a good example of what i was talking about yesterday. adding language
> about run time prevents the compiler from complaining about
> make([]byte, 10, 0)

The language used here is the same as for index expressions. We try to state
conditions that must be satisfied universally (at all times).

The additional phrase "at run-time" is used to for conditions than cannot
necessarily be checked before run-time, by any system (compiler, interpreter,
just-in-time system, etc.)

> 
> the previous sentence has the vague "must hold". i think it should be clear
the
> the compiler might complain. for one thing, this is an easy error to make,
> forgetting the order of len and cap. i've made it myself.

It now uses similar phrasing as for index expressions.

> 
> i'm starting to think the spec should shy away from saying when the error is
> detected, that it should be the implementer's decision between compiler and
> run-time, if even both exist.
> 
> maybe something as simple as this is all you need:
> 
> It is an error if n > m or if either value is negative.

The problem with this approach is that we can have legal programs that are
accepted by some compilers and not by others. That seems problematic.

> 
> this gives the compiler, if there is one, the freedom to reject the program,
but
> guarantees that if not, the run-time implementation will catch it.

[gri, 2012-10-18 18:36:38]

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-19 03:27:02]

LGTM

weasely but sure, let's go with that

[rsc, 2012-10-19 17:09:15]

LGTM

[gri, 2012-10-19 17:11:13]

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

go spec: define make() restrictions as for index expressions

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
http://codereview.appspot.com/6725053