code review 207103: specification of []int(string) and []byte(string).

specification of []int(string) and []byte(string).
also clarify other string conversions.

[r, 2010-02-16 06:30:29]

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

I'd like you to review this change.

[iant, 2010-02-16 06:51:04]

http://codereview.appspot.com/207103/diff/1001/1002
File doc/go_spec.html (right):

http://codereview.appspot.com/207103/diff/1001/1002#newcode3256
doc/go_spec.html:3256: Converting a slice of any other integer type into to a
string yields
Currently both compilers support only conversions from []byte and []int. 
Converting from other integer types is straightforward but slightly tedious as
each type has to be handled differently.  Do you see a use case for types other
than []byte and []int?

http://codereview.appspot.com/207103/diff/1001/1002#newcode3276
doc/go_spec.html:3276: Converting a string to a slice of any other integer type
yields a
Same issue here--do we want any integer type, or just []byte and []int?

[r2, 2010-02-16 06:53:20]

On Feb 16, 2010, at 5:51 PM, iant@golang.org wrote:

>
> http://codereview.appspot.com/207103/diff/1001/1002
> File doc/go_spec.html (right):
>
> http://codereview.appspot.com/207103/diff/1001/1002#newcode3256
> doc/go_spec.html:3256: Converting a slice of any other integer type  
> into
> to a string yields
> Currently both compilers support only conversions from []byte and  
> []int.
> Converting from other integer types is straightforward but slightly
> tedious as each type has to be handled differently.  Do you see a use
> case for types other than []byte and []int?

the question is what you mean by int.  do you mean
	type MyInt int
too?

also uint certainly makes sense.

i agonized over these questions but am not firm about any of the  
decisions.

>
> http://codereview.appspot.com/207103/diff/1001/1002#newcode3276
> doc/go_spec.html:3276: Converting a string to a slice of any other
> integer type yields a
> Same issue here--do we want any integer type, or just []byte and  
> []int?
>
> http://codereview.appspot.com/207103/show

[rog, 2010-02-16 09:26:46]

> Currently both compilers support only conversions from []byte and []int.
>  Converting from other integer types is straightforward but slightly
> tedious as each type has to be handled differently.  Do you see a use
> case for types other than []byte and []int?

if you know that you're dealing with a restricted subset of unicode,
then using uint16 can be useful.

[gri, 2010-02-16 17:45:56]

http://codereview.appspot.com/207103/diff/1001/1002
File doc/go_spec.html (right):

http://codereview.appspot.com/207103/diff/1001/1002#newcode3276
doc/go_spec.html:3276: Converting a string to a slice of any other integer type
yields a
On 2010/02/16 06:51:04, iant wrote:
> Same issue here--do we want any integer type, or just []byte and []int?

It seems to me that the same issues should arise with a range clause over a
string; it currently yields int code points only.

I can see the desire to have arbitrary integer types, but then the range clause
should probably support that too.

I am a bit hesitant to make these string conversions so omnipotent - to me these
look like library functions. The string -> []byte conversions (and vice versa)
are necessary of course (the only way to create a string from scratch), and the
string -> []int conversions are useful, but I'd probably leave it at that.
Perhaps one could require the int to be a 32bit integer type? Then one wouldn't
have to deal with the error case (code point too large). In any case, the
behavior of the range clause for a string should match in my opinion.

[r, 2010-02-16 23:56:22]

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

Please take another look.

[rsc, 2010-02-17 00:01:55]

I like the wording.  Restriction to []int and []byte works for me.

http://codereview.appspot.com/207103/diff/2001/3001
File doc/go_spec.html (right):

http://codereview.appspot.com/207103/diff/2001/3001#newcode3251
doc/go_spec.html:3251: the slice value is <code>nil</code>, the result is the
empty string.
I'm inclined to drop the words about nil here and in the next paragraph.  nil is
just a zero-length slice.

http://codereview.appspot.com/207103/diff/2001/3001#newcode3271
doc/go_spec.html:3271: If the string is empty, the result is <code>nil</code>.
This is interesting.  I don't think that's a necessary condition.  It should be
fine to just return any old zero-length slice.

[r, 2010-02-17 00:04:26]

http://codereview.appspot.com/207103/diff/2001/3001
File doc/go_spec.html (right):

http://codereview.appspot.com/207103/diff/2001/3001#newcode3251
doc/go_spec.html:3251: the slice value is <code>nil</code>, the result is the
empty string.
i'm inclined to leave it in, in the interest of precision.  nil is a zero-length
slice but a zero-length slice is not == nil.

http://codereview.appspot.com/207103/diff/2001/3001#newcode3271
doc/go_spec.html:3271: If the string is empty, the result is <code>nil</code>.
again, precision.

i can be talked out of this but it seems worth locking down.

[rsc, 2010-02-17 00:06:30]

LGTM

[gri, 2010-02-17 00:06:43]

http://codereview.appspot.com/207103/diff/2001/3001
File doc/go_spec.html (right):

http://codereview.appspot.com/207103/diff/2001/3001#newcode3271
doc/go_spec.html:3271: If the string is empty, the result is <code>nil</code>.
One should probably clarify that the type of nil is []byte.

http://codereview.appspot.com/207103/diff/2001/3001#newcode3281
doc/go_spec.html:3281: If the string is empty, the result is <code>nil</code>.
same here

[r, 2010-02-17 00:10:13]

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

Please take another look.

[rsc, 2010-02-17 00:12:51]

LGTM

http://codereview.appspot.com/207103/diff/2005/2006
File doc/go_spec.html (right):

http://codereview.appspot.com/207103/diff/2005/2006#newcode3877
doc/go_spec.html:3877: For values of a string type, the "range" clause iterates
over the Unicode code points
s/For values/For a value/

[gri, 2010-02-17 00:15:11]

LGTM

[r, 2010-02-17 00:24:23]

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

Please take another look.

[rsc, 2010-02-17 00:25:32]

LGTM

[r, 2010-02-17 00:26:16]

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

specification of []int(string) and []byte(string).
also clarify other string conversions.

R=rsc, iant, gri, ken2
CC=golang-dev
http://codereview.appspot.com/207103