code review 100130044: spec: clarify type properties

spec: clarify type properties

If the underlying type of a type T is a boolean, numeric,
or string type, then T is also a boolean, numeric, or
string type, respectively.

Not a language change.

Fixes issue 7551.

[gri, 2014-05-05 22:33:34]

Hello r@golang.org, rsc@golang.org, iant@golang.org, ken@golang.org (cc:
golang-codereviews@googlegroups.com),

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

[iant, 2014-05-05 23:44:11]

https://codereview.appspot.com/100130044/diff/40001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/100130044/diff/40001/doc/go_spec.html#newcode698
doc/go_spec.html:698: If the underlying type of a type <code>T</code> is a
boolean, numeric, or string type,
I'm not convinced that this sentence makes the spec any clearer.  Can we
something in the Type Declarations section instead?  Or in
{Boolean,Numeric,String} Types sections?

[gri, 2014-05-06 00:38:51]

Hello r@golang.org, rsc@golang.org, iant@golang.org, ken@golang.org (cc:
golang-codereviews@googlegroups.com),

Please take another look.

[gri, 2014-05-06 00:39:16]

PTAL

https://codereview.appspot.com/100130044/diff/40001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/100130044/diff/40001/doc/go_spec.html#newcode698
doc/go_spec.html:698: If the underlying type of a type <code>T</code> is a
boolean, numeric, or string type,
On 2014/05/05 23:44:11, iant wrote:
> I'm not convinced that this sentence makes the spec any clearer.  Can we
> something in the Type Declarations section instead?  Or in
> {Boolean,Numeric,String} Types sections?

Done.

[iant, 2014-05-06 00:57:59]

LGTM

[rh, 2014-05-06 01:34:36]

https://codereview.appspot.com/100130044/diff/120001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/100130044/diff/120001/doc/go_spec.html#newcode...
doc/go_spec.html:1807: operands of the new type.
This is true of all types, not just these, correct?

[gri, 2014-05-06 02:45:24]

https://codereview.appspot.com/100130044/diff/120001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/100130044/diff/120001/doc/go_spec.html#newcode...
doc/go_spec.html:1807: operands of the new type.
On 2014/05/06 01:34:35, rh wrote:
> This is true of all types, not just these, correct?

Fair enough - I assume you mean other (non-binary or unary) operators, such as
slicing, indexing, etc for new slices, arrays, etc. ? Deref for pointers, etc.

I'll think of a more general way of saying this.

[rh, 2014-05-06 02:48:49]

https://codereview.appspot.com/100130044/diff/120001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/100130044/diff/120001/doc/go_spec.html#newcode...
doc/go_spec.html:1807: operands of the new type.
I could have been clearer about that, sorry.  Yes, that is what I meant.  Thank
you.

[r, 2014-05-06 11:20:59]

https://codereview.appspot.com/100130044/diff/120001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/100130044/diff/120001/doc/go_spec.html#newcode...
doc/go_spec.html:1774: that has the same <a href="#Types">underlying type</a> as
an existing type.
can't you just say

... as an existing type,
and operators defined for the existing type are also defined for the new type.

then you can drop the new paragraph below and the example does all the work for
you.

[rh, 2014-05-06 12:05:30]

https://codereview.appspot.com/100130044/diff/120001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/100130044/diff/120001/doc/go_spec.html#newcode...
doc/go_spec.html:1774: that has the same <a href="#Types">underlying type</a> as
an existing type.
s/operators/operators and built-in functions/ ?

type S string
var str S

_ = len(str)            // ok
_ = strings.Fields(str) // error: requires cast

[gri, 2014-05-06 18:13:24]

PTAL

I am phrasing it a little bit more vague ("operations" rather than "operators").
If I mention operators, I need to mention built-in functions, but also index,
slice, and selector expressions, and it gets complicated to be precise here yet
it's not important for explanation of a type declaration.

This is merely a hint that existing operations still work, and each section
(operators, index, slice, selector expressions, etc.) explain the precise
details already.

https://codereview.appspot.com/100130044/diff/120001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/100130044/diff/120001/doc/go_spec.html#newcode...
doc/go_spec.html:1774: that has the same <a href="#Types">underlying type</a> as
an existing type.
On 2014/05/06 12:05:30, rh wrote:
> s/operators/operators and built-in functions/ ?
> 
> type S string
> var str S
> 
> _ = len(str)            // ok
> _ = strings.Fields(str) // error: requires cast

Done.

[rsc, 2014-05-07 02:49:25]

LGTM

[rh, 2014-05-07 12:00:26]

LGTM

[r, 2014-05-07 12:15:08]

LGTM

[iant, 2014-05-07 13:43:39]

LGTM

https://codereview.appspot.com/100130044/diff/140001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/100130044/diff/140001/doc/go_spec.html#newcode3
doc/go_spec.html:3: "Subtitle": "Version of May 5, 2014",
s/5/7/

[gri, 2014-05-07 15:42:12]

*** Submitted as https://code.google.com/p/go/source/detail?r=0680597f46ae ***

spec: clarify type properties

If the underlying type of a type T is a boolean, numeric,
or string type, then T is also a boolean, numeric, or
string type, respectively.

Not a language change.

Fixes issue 7551.

LGTM=iant, rsc, robert.hencke, r
R=r, rsc, iant, ken, robert.hencke
CC=golang-codereviews
https://codereview.appspot.com/100130044