code review 5700067: doc/go1: add justification discussions to major changes

doc/go1: add justification discussions to major changes

Fixes issue 3086.

[r, 2012-02-24 23:35:22]

Hello golang-dev@googlegroups.com,

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

[gri, 2012-02-25 00:04:21]

http://codereview.appspot.com/5700067/diff/1/doc/go1.tmpl
File doc/go1.tmpl (right):

http://codereview.appspot.com/5700067/diff/1/doc/go1.tmpl#newcode138
doc/go1.tmpl:138: if another package might want to use the library during
initialization, the library
s/might want/wanted/

http://codereview.appspot.com/5700067/diff/1/doc/go1.tmpl#newcode167
doc/go1.tmpl:167: the old language because the <code>int</code> type was used to
hold Unicode code points: each code point would waste an extra 32 bits of
storage if <code>int</code> grew from 32 bits to 64.
s/used/also used/ (?)

http://codereview.appspot.com/5700067/diff/1/doc/go1.tmpl#newcode231
doc/go1.tmpl:231: It required passing a value (usually ignored) that is
evaluated but discarded,
s/is/was/

http://codereview.appspot.com/5700067/diff/1/doc/go1.tmpl#newcode232
doc/go1.tmpl:232: plus a boolean that is nearly always the constant
<code>false</code>.
s/is/was/

http://codereview.appspot.com/5700067/diff/1/doc/go1.tmpl#newcode367
doc/go1.tmpl:367: plus  the implementations of <code>copy</code> and
<code>append</code> have never honored the restriction.
s/plus /and/

http://codereview.appspot.com/5700067/diff/1/doc/go1.tmpl#newcode427
doc/go1.tmpl:427: Function equality was problematic from an implementation
standpoint
I wouldn't emphasize the implementation here - I don't think they are hard (only
unfortunate) given a definition of equality. I think the issue is what the
correct definition is (when are two closures identical?). Maybe:

Function equality was problematic in the presence of closures (when are two
closures equal?), while map equality ...

http://codereview.appspot.com/5700067/diff/1/doc/go1.tmpl#newcode438
doc/go1.tmpl:438: provided they are composed from fields on which equality is
also defined,
s/fields/fields and elements/ (?)

http://codereview.appspot.com/5700067/diff/1/doc/go1.tmpl#newcode447
doc/go1.tmpl:447: which means that closures can be implemented more efficiently.
I don't understand how this has any bearing on closures' efficiency. As is,
every time we create a closure we create a new piece of stub code, so they were
all different (one way of defining closures); if we move to a two-pointer
representation (context + function) for closures and functions, the same
comparison would be possible (comparing context + function), but also a
different comparison (just comparing function). Either way, it's fairly
efficient. It is true, that with the current implementation, comparing closures
based on function body only, would be expensive.

Just leave away this part?

[r2, 2012-02-25 00:11:06]

On 25/02/2012, at 11:04 AM, gri@golang.org wrote:

> I don't understand how this has any bearing on closures' efficiency. As
> is, every time we create a closure we create a new piece of stub code,
> so they were all different (one way of defining closures); if we move to
> a two-pointer representation (context + function) for closures and
> functions, the same comparison would be possible (comparing context +
> function), but also a different comparison (just comparing function).
> Either way, it's fairly efficient. It is true, that with the current
> implementation, comparing closures based on function body only, would be
> expensive.

my understanding is that it affects the need to allocate when building closures.
maybe the way to say it is that the need to define equality constrains the
implementation of closures.

[r, 2012-02-25 00:16:39]

Hello golang-dev@googlegroups.com, gri@golang.org, r@google.com (cc:
golang-dev@googlegroups.com),

Please take another look.

[gri, 2012-02-25 00:37:38]

LGTM

http://codereview.appspot.com/5700067/diff/5/doc/go1.tmpl
File doc/go1.tmpl (right):

http://codereview.appspot.com/5700067/diff/5/doc/go1.tmpl#newcode438
doc/go1.tmpl:438: provided they are composed from elements on which equality is
also defined,
s/on/for/ ?

[r2, 2012-02-25 00:40:02]

On 25/02/2012, at 11:37 AM, gri@golang.org wrote:

> LGTM
> 

i'll leave this for a while in case others have comments

[kevlar, 2012-02-26 18:10:13]

LGTM

[r, 2012-02-26 20:31:41]

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

doc/go1: add justification discussions to major changes

Fixes issue 3086.

R=golang-dev, gri, r, kevlar
CC=golang-dev
http://codereview.appspot.com/5700067

[rsc, 2012-02-28 15:56:41]

Until I got to the tmpl file I didn't realize I'd been commenting on the html
file; sorry.

http://codereview.appspot.com/5700067/diff/5004/doc/go1.html
File doc/go1.html (right):

http://codereview.appspot.com/5700067/diff/5004/doc/go1.html#newcode351
doc/go1.html:351: The language specification guarantees that in assignments
The old language?

http://codereview.appspot.com/5700067/diff/5004/doc/go1.html#newcode523
doc/go1.html:523: Finally, Map equality is gone too, also except for comparison
with <code>nil</code>,
s/Map/map/

http://codereview.appspot.com/5700067/diff/5004/doc/go1.html#newcode524
doc/go1.html:524: although it may return one day in a more intuitive form.
Delete.  (I don't believe we want to be making statements about future changes.)

http://codereview.appspot.com/5700067/diff/5004/doc/go1.html#newcode1128
doc/go1.html:1128: <a href="/pkg/encoding/xml/#Encoder"><code>Encoder</code></a>
type was also     introduced.
Why all the spaces here?  Is Rietveld lying to me?