code review 6503116: spec: clarify section on string types

spec: clarify section on string types

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

[gri, 2012-09-13 21:39:10]

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

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

[iant, 2012-09-13 23:07:41]

https://codereview.appspot.com/6503116/diff/5001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/6503116/diff/5001/doc/go_spec.html#newcode792
doc/go_spec.html:792: the built-in function <a
href="#Length_and_capacity"><code>len(s)</code></a>.
I know this is parallel to the existing text, but the built-in function is not
"len(s)".  Perhaps simply say "The length of a string (its size in bytes) can be
discovered using the built-in function len."

https://codereview.appspot.com/6503116/diff/5001/doc/go_spec.html#newcode793
doc/go_spec.html:793: The length is a compile-time constant if <code>s</code> is
a string constant.
If you take the above change, then here s/s/the string/

https://codereview.appspot.com/6503116/diff/5001/doc/go_spec.html#newcode797
doc/go_spec.html:797: <code>s[i]</code> is the <code>i</code>.th byte of a
s/./'/ I guess.  Or rewrite.  I'm not sure this last clause is that useful
anyhow.

[gri, 2012-09-14 00:04:04]

PTAL

http://codereview.appspot.com/6503116/diff/5001/doc/go_spec.html
File doc/go_spec.html (right):

http://codereview.appspot.com/6503116/diff/5001/doc/go_spec.html#newcode792
doc/go_spec.html:792: the built-in function <a
href="#Length_and_capacity"><code>len(s)</code></a>.
On 2012/09/13 23:07:41, iant wrote:
> I know this is parallel to the existing text, but the built-in function is not
> "len(s)".  Perhaps simply say "The length of a string (its size in bytes) can
be
> discovered using the built-in function len."

Done.

http://codereview.appspot.com/6503116/diff/5001/doc/go_spec.html#newcode793
doc/go_spec.html:793: The length is a compile-time constant if <code>s</code> is
a string constant.
On 2012/09/13 23:07:41, iant wrote:
> If you take the above change, then here s/s/the string/

Done.

http://codereview.appspot.com/6503116/diff/5001/doc/go_spec.html#newcode797
doc/go_spec.html:797: <code>s[i]</code> is the <code>i</code>.th byte of a
On 2012/09/13 23:07:41, iant wrote:
> s/./'/ I guess.  Or rewrite.  I'm not sure this last clause is that useful
> anyhow.

Done.

The old version used italics which made the "i" in "ith" overlap with the "th".
The dot helped, but using <code> is even better.

[r, 2012-09-14 03:48:04]

LGTM

[iant, 2012-09-14 04:53:32]

LGTM

[rsc, 2012-09-14 15:41:10]

LGTM

[gri, 2012-09-14 18:32:00]

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

spec: clarify section on string types

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

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