code review 5293048: go spec: introduce rune type

go spec: introduce rune type

[gri, 2011-10-19 20:42:39]

Hello golang-dev@googlegroups.com (cc: golang-dev@googlegroups.com),

I'd like you to review this change to
https://go.googlecode.com/hg/

[iant, 2011-10-19 20:49:13]

http://codereview.appspot.com/5293048/diff/8001/doc/go_spec.html
File doc/go_spec.html (right):

http://codereview.appspot.com/5293048/diff/8001/doc/go_spec.html#newcode695
doc/go_spec.html:695: rune        alias for int
I'm not sure we should say that rune is an alias for int.  It is today, but in
the future it will be an alias for int32.  Can we just say that rune is an alias
for either int or int32?  Or should we add a note that it will change in the
future?

http://codereview.appspot.com/5293048/diff/8001/doc/go_spec.html#newcode715
doc/go_spec.html:715: <code>byte</code> and <code>rune</code>, which are an
aliases for
s/an //

http://codereview.appspot.com/5293048/diff/8001/doc/go_spec.html#newcode3375
doc/go_spec.html:3375: the equivalent <code>[]int</code>) to a string type
yields a
In the future we plan to remove the conversion to []int, so I'm not sure it
should be mentioned here.

http://codereview.appspot.com/5293048/diff/8001/doc/go_spec.html#newcode3396
doc/go_spec.html:3396: Converting a value of a string type to
<code>[]rune</code> (or <code>[]int</code>)
Again I think we should drop the mention of []int.

[rsc, 2011-10-19 21:36:49]

http://codereview.appspot.com/5293048/diff/8001/doc/go_spec.html
File doc/go_spec.html (right):

http://codereview.appspot.com/5293048/diff/8001/doc/go_spec.html#newcode695
doc/go_spec.html:695: rune        alias for int
On 2011/10/19 20:49:13, iant wrote:
> I'm not sure we should say that rune is an alias for int.  It is today, but in
> the future it will be an alias for int32.  Can we just say that rune is an
alias
> for either int or int32?  Or should we add a note that it will change in the
> future?

I think we should say that it will change in the future to int32.
The long term plan is that there be just one definition.

http://codereview.appspot.com/5293048/diff/8001/doc/go_spec.html#newcode3375
doc/go_spec.html:3375: the equivalent <code>[]int</code>) to a string type
yields a
On 2011/10/19 20:49:13, iant wrote:
> In the future we plan to remove the conversion to []int, so I'm not sure it
> should be mentioned here.

Agreed.

http://codereview.appspot.com/5293048/diff/8001/doc/go_spec.html#newcode3396
doc/go_spec.html:3396: Converting a value of a string type to
<code>[]rune</code> (or <code>[]int</code>)
On 2011/10/19 20:49:13, iant wrote:
> Again I think we should drop the mention of []int.

Agreed.

[rsc, 2011-10-19 21:41:53]

http://codereview.appspot.com/5293048/diff/9002/doc/go_spec.html
File doc/go_spec.html (right):

http://codereview.appspot.com/5293048/diff/9002/doc/go_spec.html#newcode1501
doc/go_spec.html:1501: bool byte complex64 complex128 float32 float64
add rune

http://codereview.appspot.com/5293048/diff/9002/doc/go_spec.html#newcode1514
doc/go_spec.html:1514: append cap close complex copy imag len
add delete

http://codereview.appspot.com/5293048/diff/9002/doc/go_spec.html#newcode1797
doc/go_spec.html:1797: var r  = 'a'     // r  has type int
Is this a decision or a placeholder?
I don't feel strongly, but you seemed to be
leaning heavily toward 'a' being rune.

http://codereview.appspot.com/5293048/diff/9002/doc/go_spec.html#newcode3400
doc/go_spec.html:3400: []int(MyString("白鵬翔"))  // []int{0x767d, 0x9d6c, 0x7fd4}
s/int/rune/g

[r2, 2011-10-19 21:43:03]

On Oct 19, 2011, at 2:41 PM, rsc@golang.org wrote:

> 
> http://codereview.appspot.com/5293048/diff/9002/doc/go_spec.html
> File doc/go_spec.html (right):
> 
> http://codereview.appspot.com/5293048/diff/9002/doc/go_spec.html#newcode1501
> doc/go_spec.html:1501: bool byte complex64 complex128 float32 float64
> add rune
> 
> http://codereview.appspot.com/5293048/diff/9002/doc/go_spec.html#newcode1514
> doc/go_spec.html:1514: append cap close complex copy imag len
> add delete
> 
> http://codereview.appspot.com/5293048/diff/9002/doc/go_spec.html#newcode1797
> doc/go_spec.html:1797: var r  = 'a'     // r  has type int
> Is this a decision or a placeholder?
> I don't feel strongly, but you seemed to be
> leaning heavily toward 'a' being rune.

i'd rather not mix the decision about the type of character constants into this
discussion.

-rob

[gri, 2011-10-19 21:44:16]

PTAL

http://codereview.appspot.com/5293048/diff/8001/doc/go_spec.html
File doc/go_spec.html (right):

http://codereview.appspot.com/5293048/diff/8001/doc/go_spec.html#newcode2
doc/go_spec.html:2: <!-- subtitle Version of October 19, 2011 -->
changed to presumed submission date 10/25

http://codereview.appspot.com/5293048/diff/8001/doc/go_spec.html#newcode695
doc/go_spec.html:695: rune        alias for int
On 2011/10/19 20:49:13, iant wrote:
> I'm not sure we should say that rune is an alias for int.  It is today, but in
> the future it will be an alias for int32.  Can we just say that rune is an
alias
> for either int or int32?  Or should we add a note that it will change in the
> future?

Done.

http://codereview.appspot.com/5293048/diff/8001/doc/go_spec.html#newcode695
doc/go_spec.html:695: rune        alias for int
On 2011/10/19 21:36:49, rsc wrote:
> On 2011/10/19 20:49:13, iant wrote:
> > I'm not sure we should say that rune is an alias for int.  It is today, but
in
> > the future it will be an alias for int32.  Can we just say that rune is an
> alias
> > for either int or int32?  Or should we add a note that it will change in the
> > future?
> 
> I think we should say that it will change in the future to int32.
> The long term plan is that there be just one definition.

Done.

http://codereview.appspot.com/5293048/diff/8001/doc/go_spec.html#newcode715
doc/go_spec.html:715: <code>byte</code> and <code>rune</code>, which are an
aliases for
On 2011/10/19 20:49:13, iant wrote:
> s/an //

Done.

http://codereview.appspot.com/5293048/diff/8001/doc/go_spec.html#newcode3375
doc/go_spec.html:3375: the equivalent <code>[]int</code>) to a string type
yields a
On 2011/10/19 20:49:13, iant wrote:
> In the future we plan to remove the conversion to []int, so I'm not sure it
> should be mentioned here.

Done.

http://codereview.appspot.com/5293048/diff/8001/doc/go_spec.html#newcode3375
doc/go_spec.html:3375: the equivalent <code>[]int</code>) to a string type
yields a
On 2011/10/19 21:36:49, rsc wrote:
> On 2011/10/19 20:49:13, iant wrote:
> > In the future we plan to remove the conversion to []int, so I'm not sure it
> > should be mentioned here.
> 
> Agreed.

Done.

http://codereview.appspot.com/5293048/diff/8001/doc/go_spec.html#newcode3396
doc/go_spec.html:3396: Converting a value of a string type to
<code>[]rune</code> (or <code>[]int</code>)
On 2011/10/19 21:36:49, rsc wrote:
> On 2011/10/19 20:49:13, iant wrote:
> > Again I think we should drop the mention of []int.
> 
> Agreed.

Done.

http://codereview.appspot.com/5293048/diff/8001/doc/go_spec.html#newcode3396
doc/go_spec.html:3396: Converting a value of a string type to
<code>[]rune</code> (or <code>[]int</code>)
On 2011/10/19 20:49:13, iant wrote:
> Again I think we should drop the mention of []int.

Done.

[rsc, 2011-10-19 21:52:08]

LGTM

But please leave unsubmitted.  We'll clpatch+submit
when we do the big push next week.

[gri, 2011-10-19 21:52:45]

PTAL

http://codereview.appspot.com/5293048/diff/9002/doc/go_spec.html
File doc/go_spec.html (right):

http://codereview.appspot.com/5293048/diff/9002/doc/go_spec.html#newcode1501
doc/go_spec.html:1501: bool byte complex64 complex128 float32 float64
On 2011/10/19 21:41:53, rsc wrote:
> add rune

Done.

http://codereview.appspot.com/5293048/diff/9002/doc/go_spec.html#newcode1514
doc/go_spec.html:1514: append cap close complex copy imag len
On 2011/10/19 21:41:53, rsc wrote:
> add delete

Done.

http://codereview.appspot.com/5293048/diff/9002/doc/go_spec.html#newcode1797
doc/go_spec.html:1797: var r  = 'a'     // r  has type int
On 2011/10/19 21:41:53, rsc wrote:
> Is this a decision or a placeholder?
> I don't feel strongly, but you seemed to be
> leaning heavily toward 'a' being rune.

I think this is an independent change and doesn't have to be done now. However,
the advantage of doing it now would be that it could be done w/o having an
effect (since rune == int).

I just added an example to illustrate the status quo (unchanged). Happy to
remove it. Opinions?

http://codereview.appspot.com/5293048/diff/9002/doc/go_spec.html#newcode3400
doc/go_spec.html:3400: []int(MyString("白鵬翔"))  // []int{0x767d, 0x9d6c, 0x7fd4}
On 2011/10/19 21:41:53, rsc wrote:
> s/int/rune/g

Done.

[iant, 2011-10-19 21:54:24]

LGTM

[r, 2011-10-19 21:59:01]

LGTM

http://codereview.appspot.com/5293048/diff/13001/doc/go_spec.html
File doc/go_spec.html (right):

http://codereview.appspot.com/5293048/diff/13001/doc/go_spec.html#newcode717
doc/go_spec.html:717: future), respectively.
To avoid portability issues, all numeric types are distinct except byte, which
is an alias for uint8, and rune, which is an alias for int (to become int32 in a
later version of Go).

[gri, 2011-10-19 22:02:08]

http://codereview.appspot.com/5293048/diff/13001/doc/go_spec.html
File doc/go_spec.html (right):

http://codereview.appspot.com/5293048/diff/13001/doc/go_spec.html#newcode717
doc/go_spec.html:717: future), respectively.
On 2011/10/19 21:59:02, r wrote:
> To avoid portability issues, all numeric types are distinct except byte, which
> is an alias for uint8, and rune, which is an alias for int (to become int32 in
a
> later version of Go).

Done.

[rsc, 2011-11-01 05:09:27]

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

go spec: introduce rune type

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

Committer: Russ Cox <rsc@golang.org>