go1.17rc2 fails to compile slice-to-array-pointer conversions if go.mod doesn't specify go directive

[tapi...@gmail.com]

// main.go

package main

func main() {
    var s = []int{1, 2, 3}
    var pa = (*[2]int)(s[1:])
    println(pa[1])
}

$ go run main.go
# command-line-arguments
./main.go:6:23: cannot convert s[1:] (type []int) to type *[2]int:
    conversion of slices to array pointers only supported as of -lang=go1.17

Is it the deliberate design? Shouldn't the lang value be the highest language version supported by the current used toolchain?

[Ian Lance Taylor]

This is deliberate design. The idea is that if you put "go 1.16" in
your go.mod file you can reasonably assume that your package will be
usable by people who are still using Go 1.16. If you don't care
whether those people can build your package, go ahead and change to
1.17.

Ian

[tapi...@gmail.com]

But by not specifying the language version in go.mod, I think most people would expect to use the latest features.

In other words, the default language version gc uses should be the same as the version of the toolchain containing gc.

BTW, what is the default language version used by gc version go1.17rc2?

[tapi...@gmail.com]

BTW,

go run -gcflags="-lang=go1.17" main.go

doesn't work either.

[Cuong Manh Le]

> go run -gcflags="-lang=go1.17" main.go

>

> doesn't work either.

Because what was run:

```

/Users/cuonglm/sdk/gotip/pkg/tool/darwin_arm64/compile -o $WORK/b001/_pkg_.a -trimpath "$WORK/b001=>" -shared -lang=go1.17 -p main -lang=go1.16 -complete -buildid iarBRwadYSTC65zcr7pK/iarBRwadYSTC65zcr7pK -dwarf=false -D _/Users/cuonglm/t -importcfg $WORK/b001/importcfg -pack ./main.go $WORK/b001/_gomod_.go

```

Notice "-lang" is passed two times, and the later "-lang=go1.16" wins.

Cuong Manh Le

https://cuonglm.xyz

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/06c2c090-d73d-4642-9b16-493e716222c4n%40googlegroups.com.

[tapi...@gmail.com]

So, it is a bug? Or not? I'm some confused.

[Ian Lance Taylor]

On Wed, Aug 11, 2021 at 5:44 PM tapi...@gmail.com <tapi...@gmail.com> wrote:
>
> But by not specifying the language version in go.mod, I think most people would expect to use the latest features.
> In other words, the default language version gc uses should be the same as the version of the toolchain containing gc.

I believe it is. If I run "go mod init" then in the result go.mod
file I see the current language version.

> BTW, what is the default language version used by gc version go1.17rc2?

1.17

Ian

> On Wednesday, August 11, 2021 at 4:46:06 PM UTC-4 Ian Lance Taylor wrote:
>>
>> On Wed, Aug 11, 2021 at 7:45 AM tapi...@gmail.com <tapi...@gmail.com> wrote:
>> >
>> > // main.go
>> > package main
>> >
>> > func main() {
>> > var s = []int{1, 2, 3}
>> > var pa = (*[2]int)(s[1:])
>> > println(pa[1])
>> > }
>> >
>> > $ go run main.go
>> > # command-line-arguments
>> > ./main.go:6:23: cannot convert s[1:] (type []int) to type *[2]int:
>> > conversion of slices to array pointers only supported as of -lang=go1.17
>> >
>> > Is it the deliberate design? Shouldn't the lang value be the highest language version supported by the current used toolchain?
>>
>> This is deliberate design. The idea is that if you put "go 1.16" in
>> your go.mod file you can reasonably assume that your package will be
>> usable by people who are still using Go 1.16. If you don't care
>> whether those people can build your package, go ahead and change to
>> 1.17.
>>
>> Ian
>

> --
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/ba38d473-a6ce-480a-b688-6d2e084fd90dn%40googlegroups.com.

[Ian Lance Taylor]

On Wed, Aug 11, 2021 at 6:51 PM Cuong Manh Le <cuong.m...@gmail.com> wrote:
>
> > go run -gcflags="-lang=go1.17" main.go
> >
> > doesn't work either.
>
> Because what was run:
>
> ```
> /Users/cuonglm/sdk/gotip/pkg/tool/darwin_arm64/compile -o $WORK/b001/_pkg_.a -trimpath "$WORK/b001=>" -shared -lang=go1.17 -p main -lang=go1.16 -complete -buildid iarBRwadYSTC65zcr7pK/iarBRwadYSTC65zcr7pK -dwarf=false -D _/Users/cuonglm/t -importcfg $WORK/b001/importcfg -pack ./main.go $WORK/b001/_gomod_.go
> ```
>
> Notice "-lang" is passed two times, and the later "-lang=go1.16" wins.

Passing the default -lang option after the -gcflags seems like a bug, though.

Ian

[tapi...@gmail.com]

On Thursday, August 12, 2021 at 12:12:13 AM UTC-4 Ian Lance Taylor wrote:

On Wed, Aug 11, 2021 at 5:44 PM tapi...@gmail.com <tapi...@gmail.com> wrote:
>
> But by not specifying the language version in go.mod, I think most people would expect to use the latest features.
> In other words, the default language version gc uses should be the same as the version of the toolchain containing gc.

I believe it is. If I run "go mod init" then in the result go.mod
file I see the current language version.

My project was created long before. There is not the "go" directive in go.mod.

Does it mean I must run "go mod tidy" before run other go commands since Go 1.17?

[Ian Lance Taylor]

On Wed, Aug 11, 2021 at 9:16 PM tapi...@gmail.com <tapi...@gmail.com> wrote:
>
> On Thursday, August 12, 2021 at 12:12:13 AM UTC-4 Ian Lance Taylor wrote:
>>
>> On Wed, Aug 11, 2021 at 5:44 PM tapi...@gmail.com <tapi...@gmail.com> wrote:
>> >
>> > But by not specifying the language version in go.mod, I think most people would expect to use the latest features.
>> > In other words, the default language version gc uses should be the same as the version of the toolchain containing gc.
>>
>> I believe it is. If I run "go mod init" then in the result go.mod
>> file I see the current language version.
>
>
> My project was created long before. There is not the "go" directive in go.mod.
>
> Does it mean I must run "go mod tidy" before run other go commands since Go 1.17?

You will need to edit the "go" line in your go.mod file to your
desired language version, or run "go mod edit -go=1.17". Running "go
mod tidy" will not change the language version in your go.mod file,
nor should it.

Ian

[tapi...@gmail.com]

But "go mod tidy" will add the "go 1.17" line if the directive line doesn't exist there. It will help.

Ian, I still don't understand why gc doesn't think the language version is go1.17 if the directive is missing.

It looks, without this line, Go 1.14 introduced overlapping interface embedding code compiles okay.

So gc 1.17rc2 must use a language version in [1.14, 1.17).

[tapi...@gmail.com]

OK, I just found this: https://github.com/golang/go/issues/44976

It looks the language version is indeed defaulted to 1.16.