code review 6584065: go spec: conversion types starting with "func" must be ...

go spec: conversion types starting with "func" must be parenthesized

Also: Be explicit what operator means with respect to conversion types.

The parenthesis requirement is a language change. At the moment,
literal function types in conversions that cannot possibly be
followed by a '(' don't need parentheses. For instance:

        func(int)int(x)  ->  same as (func(int)int)(x)
        func()()(x)      ->  same as (func())(x)

but:

        func(int)(x)	 ->  could be func(int)x {...}

Fixes issue 4109.

[gri, 2012-10-03 01:15:03]

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

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

[r, 2012-10-03 03:19:44]

LGTM
blech

[iant, 2012-10-03 17:56:30]

This seems fine in concept but I'm concerned about Go 1.  Implementing this
change in the compilers means that some code that is currently accepted will
start being rejected.  And that code was valid according to the language spec
before this change.

So I think we should:

1) Write some tests for the current compiler behaviour and add them to the test
directory.  I don't see any tests for this there at present though I didn't look
exhaustively.

2) Change gofmt so that when it sees code like
    x := func()int(f)
it rewrites it as
    x := (func()int)(f)

3) Change the language spec as per this CL.  Perhaps add an implementation note
saying that the old form is accepted; not sure if we need that note or not.

4) Create an issue saying that we should remove this behaviour from the
compilers for Go 2.

I know this procedure is a pain, but I'm not comfortable breaking possible
working Go 1 programs for something like this.  Happy to hear other opinions.

[gri, 2012-10-03 20:01:26]

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

Please take another look.

[iant, 2012-10-03 20:10:12]

LGTM

[iant, 2012-10-03 20:10:47]

LGTM

https://codereview.appspot.com/6584065/diff/7001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/6584065/diff/7001/doc/go_spec.html#newcode3495
doc/go_spec.html:3495: Implementation restriction: For backward-compatibility
with the Go 1 language
Perhaps s/restriction/note/ , since this is not actually a restriction.

[gri, 2012-10-03 20:19:09]

We have other "implementation restrictions" in the spec that are not real
restrictions (but loosen then spec); hence I kept the same notation. This
makes it easier to search for them.

- gri


On Wed, Oct 3, 2012 at 1:10 PM, <iant@golang.org> wrote:

> LGTM
>
>
>
https://codereview.appspot.**com/6584065/diff/7001/doc/go_**spec.html<https:/...
> File doc/go_spec.html (right):
>
> https://codereview.appspot.**com/6584065/diff/7001/doc/go_**
>
spec.html#newcode3495<https://codereview.appspot.com/6584065/diff/7001/doc/go_spec.html#newcode3495>
> doc/go_spec.html:3495: Implementation restriction: For
> backward-compatibility with the Go 1 language
> Perhaps s/restriction/note/ , since this is not actually a restriction.
>
>
https://codereview.appspot.**com/6584065/<https://codereview.appspot.com/6584...
>

[iant2, 2012-10-03 20:29:17]

LGTM

On Wed, Oct 3, 2012 at 1:19 PM, Robert Griesemer <gri@golang.org> wrote:
> We have other "implementation restrictions" in the spec that are not real
> restrictions (but loosen then spec); hence I kept the same notation. This
> makes it easier to search for them.
>
> - gri
>
>
> On Wed, Oct 3, 2012 at 1:10 PM, <iant@golang.org> wrote:
>>
>> LGTM
>>
>>
>> https://codereview.appspot.com/6584065/diff/7001/doc/go_spec.html
>> File doc/go_spec.html (right):
>>
>>
>>
https://codereview.appspot.com/6584065/diff/7001/doc/go_spec.html#newcode3495
>> doc/go_spec.html:3495: Implementation restriction: For
>> backward-compatibility with the Go 1 language
>> Perhaps s/restriction/note/ , since this is not actually a restriction.
>>
>> https://codereview.appspot.com/6584065/
>
>

[r, 2012-10-03 20:40:48]

LGTM

https://codereview.appspot.com/6584065/diff/7001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/6584065/diff/7001/doc/go_spec.html#newcode3497
doc/go_spec.html:3497: in conversions which are not ambiguous.
s/which/that/

in any case: the conversion's not ambiguous, it's the syntax. so maybe:
in conversions where the syntax is unambiguous.

[gri, 2012-10-03 20:46:45]

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

go spec: conversion types starting with "func" must be parenthesized

Also: Be explicit what operator means with respect to conversion types.

The parenthesis requirement is a language change. At the moment,
literal function types in conversions that cannot possibly be
followed by a '(' don't need parentheses. For instance:

        func(int)int(x)  ->  same as (func(int)int)(x)
        func()()(x)      ->  same as (func())(x)

but:

        func(int)(x)	 ->  could be func(int)x {...}

Fixes issue 4109.

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

[rsc, 2012-10-05 21:17:02]

LGTM