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

[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.

On Thursday, August 12, 2021 at 12:36:37 AM UTC-4 tapi...@gmail.com wrote:

> On Thursday, August 12, 2021 at 12:22:08 AM UTC-4 Ian Lance Taylor wrote:
>
>> On Wed, Aug 11, 2021 at 9:16 PM 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  
>> 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 
>>
>
> 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).
>
>
>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e5d13236-8fa3-45d7-8cc1-e6d3044938abn%40googlegroups.com.

[go-nuts] JWZ Email Threading algorithm now available

[Jim Idle]

A few people were talking about email parsing etc on this forum, so perhaps 
this will be useful to some people:

https://github.com/gatherstars-com/jwz

Fully implements the JWZ Threading algorithm in go. It provides:

   - Threading via interface
   - Sort with custom comparator func
   - Walk with custom visitor function
   - Example program to parse emails using Enmime, thread them, sort them, 
   then use tview to display a rudimentary tree view in the console

Cheers,

Jim

PS: Ignore the "go report: F" badge. It is actually A+, but the go report 
site is down at the moment it seems.


-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/4df4216d-c345-4d2f-8c21-c21559e0d4e0n%40googlegroups.com.

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

[tapi...@gmail.com]

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

> On Wed, Aug 11, 2021 at 9:16 PM 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  
> 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 
>

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).



-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a2d35b18-ecb4-4f77-89ba-cfb8a486f249n%40googlegroups.com.

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

[Ian Lance Taylor]

On Wed, Aug 11, 2021 at 9:16 PM 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  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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUwBSKPe8F0%3D8POUrLn%2BpjpAQwCWxv7hB%2BMptHo86yneg%40mail.gmail.com.

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

[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  
> 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?
 

>
> > 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  
> 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.
>  
>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/3a0d3db3-a6d0-47a9-b32c-1d88b96e3391n%40googlegroups.com.

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

[Ian Lance Taylor]

On Wed, Aug 11, 2021 at 6:51 PM Cuong Manh Le  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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWz8SEYRfWXUhM13XQtUnx39qQ_QzsKWFNyZpkdrWkKeg%40mail.gmail.com.

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

[tapi...@gmail.com]

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

On Wednesday, August 11, 2021 at 9:51:55 PM UTC-4 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.
>
> Cuong Manh Le
> https://cuonglm.xyz
>
>
> On Thu, Aug 12, 2021 at 7:56 AM tapi...@gmail.com  
> wrote:
>
>> BTW, 
>>
>> go run -gcflags="-lang=go1.17" main.go
>>
>> doesn't work either.
>>
>> On Wednesday, August 11, 2021 at 10:45:05 AM UTC-4 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?
>>>
>> -- 
>> 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
>>  
>> 
>> .
>>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/51f7a80c-befe-45b5-9521-f30bc8d7d5f1n%40googlegroups.com.

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

[Ian Lance Taylor]

On Wed, Aug 11, 2021 at 5:44 PM 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  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+unsubscr...@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.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVwd9moqbgYCJovrPqPBnQ6zjfHmSxb0tc-TRXeM3GuEA%40mail.gmail.com.

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

[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


On Thu, Aug 12, 2021 at 7:56 AM tapi...@gmail.com 
wrote:

> BTW,
>
> go run -gcflags="-lang=go1.17" main.go
>
> doesn't work either.
>
> On Wednesday, August 11, 2021 at 10:45:05 AM UTC-4 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?
>>
> --
> 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+unsubscr...@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
> 
> .
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALS7p_dgwuZ%3DNcjf0HcX0SiFt_%2BwMAW3aUsN%3D6r2XYpzRqGDow%40mail.gmail.com.

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

[tapi...@gmail.com]

BTW, 

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

doesn't work either.

On Wednesday, August 11, 2021 at 10:45:05 AM UTC-4 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?
>

-- 
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+unsubscr...@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.

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

[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?

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  
> 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+unsubscr...@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.

Re: [go-nuts] `go list` across multiple modules?

['Tim Hockin' via golang-nuts]

Great, thanks for that.  I fully appreciate "a lot going on" :)

I want to solve this, but it's beyond my limited understanding of Go's 
impls and beyond my limited free-time to overcome that lack of 
understanding.

Please consider me a willing partner when the time comes to poke at this 
beehive again.

On Wednesday, August 11, 2021 at 1:11:58 PM UTC-7 jayc...@google.com wrote:

> Despite what the blog post says, Go 1.17 won't drop support for 
> GO111MODULE or GOPATH mode. It will be more or less the same as GOPATH mode.
>
> We'll continue to work on these issues and others that are blocking people 
> from migrating. I apologize for the slow progress–we have a lot going on.
>
> On Wed, Aug 11, 2021 at 12:34 PM Tim Hockin  wrote:
>
>> Hi all.  I realized that https://blog.golang.org/go116-module-changes 
>> says "We plan to drop support for GOPATH mode in Go 1.17. In other words, 
>> Go 1.17 will ignore GO111MODULE".  This will  break Kubernetes - our builds 
>> will be orders of magnitude slower.
>>
>> AFAICT, https://github.com/golang/go/issues/43806 has had no progress 
>> and https://github.com/golang/go/issues/43733 is still open, too.  I 
>> have zero confidence that these are the ONLY issues, and until I can get 
>> past them, I can't really find out.
>>
>> Please advise - how should I proceed?
>>
>> Tim
>>
>>
>> On Wed, Jan 20, 2021 at 12:57 PM Tim Hockin  wrote:
>>
>>> As long as these things are bugs and not "that's not how it works or 
>>> will ever work", I have some hope.  This is a back-burner exploration for 
>>> me, so I am not in a panic.  Every now and again I will circle back and see 
>>> if anything new happens :)
>>>
>>> On Wed, Jan 20, 2021 at 10:50 AM Jay Conrod  wrote:
>>>
 You appear to have discovered another new bug. Sorry for that. I've 
 opened #43806  to track it.

 With that bug, it doesn't look like `go list` with local paths 
 (relative or absolute) in a repository with nested replacement directories 
 will work (at least not yet).

 `go list` should still work on full packages paths, but I'm not sure 
 there's an easy way to resolve directory paths to package paths, other 
 than 
 by walking up the directory tree to the nearest go.mod and reading the 
 module path from there.

 On Tue, Jan 19, 2021 at 8:06 PM Tim Hockin  wrote:

>
>
> On Tue, Jan 19, 2021 at 7:54 AM Jay Conrod  wrote:
>
>> By the way, I'm not sure if you're already doing this, but if you can 
>> batch all of the `go list` runs (or go/packages 
>> .Load) together per module 
>> (passing an argument per package), that will be much faster than loading 
>> individual packages with separate `go list` calls. It will save `go 
>> list` 
>> from having to load the module graph and common sets of dependencies 
>> multiple times.
>>
>> If you need to load all the packages in a module, you can also use an 
>> argument like ./... from the root directory of the module to load 
>> everything there (excluding modules in subdirectories).
>>
>
> Yeah, I am trying that but tripping on the "does not contain package" 
> error.
>  
>
>>
>> On Tue, Jan 19, 2021 at 10:02 AM Jay Conrod  
>> wrote:
>>
>>> > Interesting - is the difference the absolute paths vs relative?
>>>
>>> It looks like the bug has to do with whether the directory is below 
>>> the main module root directory or not. If it is, the go command takes a 
>>> path that assumes it's part of the main module, which it's not.
>>>
>>> > I hoped maybe `-modfile` would do the same trick, but alas not:
>>>
>>> -modfile lets you change the effective content of go.mod but not the 
>>> module root directory. Unfortunately it doesn't look like that can be 
>>> used 
>>> to work around the issue.
>>>
>>> > It seems that is because the "main" (top-level dir) go.mod has
>>> > `replace` directives with relative paths, which kubernetes really
>>> > does.
>>>
>>> You may need to copy those over to the tmp go.mod and adjust the 
>>> paths. Sorry this has gotten pretty involved.
>>>
>>> > Yeah, I noticed.  When GO111MODULE=off, everything I am doing is 
>>> much
>>> > faster.  I'm wary of depending on that forever, though.
>>>
>>> Module-aware mode is quite a bit more complicated than GOPATH mode, 
>>> so to some degree it's not surprising it's slower... it's surprising 
>>> that 
>>> it's a LOT slower though. I expect there's some optimization work for 
>>> us to 
>>> do in the next development cycle.
>>>
>>> We would eventually like to deprecate GOPATH mode though, so it's a 
>>> good idea not to depend on it in new tooling today. 'go list' should be 
>>> fine to get package dependency info in either module 

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

[Ian Lance Taylor]

On Wed, Aug 11, 2021 at 7:45 AM 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWvM7DnBg_gRA5p-oaSJ_rqcv%3DnP1%2BEPVCj%2BM0X2CwDaw%40mail.gmail.com.

Re: [go-nuts] `go list` across multiple modules?

['Jay Conrod' via golang-nuts]

Despite what the blog post says, Go 1.17 won't drop support for GO111MODULE
or GOPATH mode. It will be more or less the same as GOPATH mode.

We'll continue to work on these issues and others that are blocking people
from migrating. I apologize for the slow progress–we have a lot going on.

On Wed, Aug 11, 2021 at 12:34 PM Tim Hockin  wrote:

> Hi all.  I realized that https://blog.golang.org/go116-module-changes
> says "We plan to drop support for GOPATH mode in Go 1.17. In other words,
> Go 1.17 will ignore GO111MODULE".  This will  break Kubernetes - our builds
> will be orders of magnitude slower.
>
> AFAICT, https://github.com/golang/go/issues/43806 has had no progress and
> https://github.com/golang/go/issues/43733 is still open, too.  I have
> zero confidence that these are the ONLY issues, and until I can get past
> them, I can't really find out.
>
> Please advise - how should I proceed?
>
> Tim
>
>
> On Wed, Jan 20, 2021 at 12:57 PM Tim Hockin  wrote:
>
>> As long as these things are bugs and not "that's not how it works or will
>> ever work", I have some hope.  This is a back-burner exploration for me, so
>> I am not in a panic.  Every now and again I will circle back and see if
>> anything new happens :)
>>
>> On Wed, Jan 20, 2021 at 10:50 AM Jay Conrod  wrote:
>>
>>> You appear to have discovered another new bug. Sorry for that. I've
>>> opened #43806  to track it.
>>>
>>> With that bug, it doesn't look like `go list` with local paths (relative
>>> or absolute) in a repository with nested replacement directories will work
>>> (at least not yet).
>>>
>>> `go list` should still work on full packages paths, but I'm not sure
>>> there's an easy way to resolve directory paths to package paths, other than
>>> by walking up the directory tree to the nearest go.mod and reading the
>>> module path from there.
>>>
>>> On Tue, Jan 19, 2021 at 8:06 PM Tim Hockin  wrote:
>>>


 On Tue, Jan 19, 2021 at 7:54 AM Jay Conrod 
 wrote:

> By the way, I'm not sure if you're already doing this, but if you can
> batch all of the `go list` runs (or go/packages
> .Load) together per module (passing
> an argument per package), that will be much faster than loading individual
> packages with separate `go list` calls. It will save `go list` from having
> to load the module graph and common sets of dependencies multiple times.
>
> If you need to load all the packages in a module, you can also use an
> argument like ./... from the root directory of the module to load
> everything there (excluding modules in subdirectories).
>

 Yeah, I am trying that but tripping on the "does not contain package"
 error.


>
> On Tue, Jan 19, 2021 at 10:02 AM Jay Conrod 
> wrote:
>
>> > Interesting - is the difference the absolute paths vs relative?
>>
>> It looks like the bug has to do with whether the directory is below
>> the main module root directory or not. If it is, the go command takes a
>> path that assumes it's part of the main module, which it's not.
>>
>> > I hoped maybe `-modfile` would do the same trick, but alas not:
>>
>> -modfile lets you change the effective content of go.mod but not the
>> module root directory. Unfortunately it doesn't look like that can be 
>> used
>> to work around the issue.
>>
>> > It seems that is because the "main" (top-level dir) go.mod has
>> > `replace` directives with relative paths, which kubernetes really
>> > does.
>>
>> You may need to copy those over to the tmp go.mod and adjust the
>> paths. Sorry this has gotten pretty involved.
>>
>> > Yeah, I noticed.  When GO111MODULE=off, everything I am doing is
>> much
>> > faster.  I'm wary of depending on that forever, though.
>>
>> Module-aware mode is quite a bit more complicated than GOPATH mode,
>> so to some degree it's not surprising it's slower... it's surprising that
>> it's a LOT slower though. I expect there's some optimization work for us 
>> to
>> do in the next development cycle.
>>
>> We would eventually like to deprecate GOPATH mode though, so it's a
>> good idea not to depend on it in new tooling today. 'go list' should be
>> fine to get package dependency info in either module mode or GOPATH mode.
>> go/packages  is useful if you need
>> additional information on top of that (parsed syntax trees, type info).
>>
>> > I want to run a slow codegen process only if the packages it depends
>> > on have ACTUALLY changed (mtime is a good enough proxy) and I don't
>> > know a priori which packages need codegen.  I want to scan the file
>> > tree, find the files that need codegen, check their deps, and only
>> > then run the codegen.
>>
>> How much dependency 

Re: [go-nuts] `go list` across multiple modules?

['Tim Hockin' via golang-nuts]

Hi all.  I realized that https://blog.golang.org/go116-module-changes says
"We plan to drop support for GOPATH mode in Go 1.17. In other words, Go
1.17 will ignore GO111MODULE".  This will  break Kubernetes - our builds
will be orders of magnitude slower.

AFAICT, https://github.com/golang/go/issues/43806 has had no progress and
https://github.com/golang/go/issues/43733 is still open, too.  I have zero
confidence that these are the ONLY issues, and until I can get past them, I
can't really find out.

Please advise - how should I proceed?

Tim


On Wed, Jan 20, 2021 at 12:57 PM Tim Hockin  wrote:

> As long as these things are bugs and not "that's not how it works or will
> ever work", I have some hope.  This is a back-burner exploration for me, so
> I am not in a panic.  Every now and again I will circle back and see if
> anything new happens :)
>
> On Wed, Jan 20, 2021 at 10:50 AM Jay Conrod  wrote:
>
>> You appear to have discovered another new bug. Sorry for that. I've
>> opened #43806  to track it.
>>
>> With that bug, it doesn't look like `go list` with local paths (relative
>> or absolute) in a repository with nested replacement directories will work
>> (at least not yet).
>>
>> `go list` should still work on full packages paths, but I'm not sure
>> there's an easy way to resolve directory paths to package paths, other than
>> by walking up the directory tree to the nearest go.mod and reading the
>> module path from there.
>>
>> On Tue, Jan 19, 2021 at 8:06 PM Tim Hockin  wrote:
>>
>>>
>>>
>>> On Tue, Jan 19, 2021 at 7:54 AM Jay Conrod  wrote:
>>>
 By the way, I'm not sure if you're already doing this, but if you can
 batch all of the `go list` runs (or go/packages
 .Load) together per module (passing
 an argument per package), that will be much faster than loading individual
 packages with separate `go list` calls. It will save `go list` from having
 to load the module graph and common sets of dependencies multiple times.

 If you need to load all the packages in a module, you can also use an
 argument like ./... from the root directory of the module to load
 everything there (excluding modules in subdirectories).

>>>
>>> Yeah, I am trying that but tripping on the "does not contain package"
>>> error.
>>>
>>>

 On Tue, Jan 19, 2021 at 10:02 AM Jay Conrod 
 wrote:

> > Interesting - is the difference the absolute paths vs relative?
>
> It looks like the bug has to do with whether the directory is below
> the main module root directory or not. If it is, the go command takes a
> path that assumes it's part of the main module, which it's not.
>
> > I hoped maybe `-modfile` would do the same trick, but alas not:
>
> -modfile lets you change the effective content of go.mod but not the
> module root directory. Unfortunately it doesn't look like that can be used
> to work around the issue.
>
> > It seems that is because the "main" (top-level dir) go.mod has
> > `replace` directives with relative paths, which kubernetes really
> > does.
>
> You may need to copy those over to the tmp go.mod and adjust the
> paths. Sorry this has gotten pretty involved.
>
> > Yeah, I noticed.  When GO111MODULE=off, everything I am doing is much
> > faster.  I'm wary of depending on that forever, though.
>
> Module-aware mode is quite a bit more complicated than GOPATH mode, so
> to some degree it's not surprising it's slower... it's surprising that 
> it's
> a LOT slower though. I expect there's some optimization work for us to do
> in the next development cycle.
>
> We would eventually like to deprecate GOPATH mode though, so it's a
> good idea not to depend on it in new tooling today. 'go list' should be
> fine to get package dependency info in either module mode or GOPATH mode.
> go/packages  is useful if you need
> additional information on top of that (parsed syntax trees, type info).
>
> > I want to run a slow codegen process only if the packages it depends
> > on have ACTUALLY changed (mtime is a good enough proxy) and I don't
> > know a priori which packages need codegen.  I want to scan the file
> > tree, find the files that need codegen, check their deps, and only
> > then run the codegen.
>
> How much dependency info do you need? If the codegen is only within
> packages with files that have changed, 'go list' might be overkill (it
> always loads dependencies, even if they aren't printed). If you need
> dependencies or reverse dependencies, 'go list' or go/packages
>  are probably the right tools.
>
> On Fri, Jan 15, 2021 at 6:43 PM Tim Hockin  wrote:
>
>> On Fri, Jan 15, 2021 at 2:17 PM Jay Conrod 
>> wrote:
>> >

Re: [go-nuts] The behavior of the function variable which points to the struct method

[Sean Liao]

Perhaps this section of the spec will 
help: https://golang.org/ref/spec#Method_declarations

> The type of a method is the type of a function with the receiver as first 
argument

So there's only a single copy of the function code, but the argument passed 
to it is copied
>From your original example: `gz.Display() == Zoo.Display(*gz)`

On Wednesday, August 11, 2021 at 7:59:57 PM UTC+2 lege...@gmail.com wrote:

> Thank you so much. 
>
> Your explanation makes my understanding of this problem more and more 
> clear.
>
> However, since I have been a C programmer for a long time, I still don't 
> understand the implementation of the function variable in Golang very well. 
> I think I need to do some inspection about function variable in Golang to 
> know more details.
>
> On Wednesday, August 11, 2021 at 1:23:44 AM UTC-7 Brian Candler wrote:
>
>> On Tuesday, 10 August 2021 at 22:50:00 UTC+1 lege...@gmail.com wrote:
>>
>>> And I'm still a little confused here, you know when we use the struct 
>>> method directly, it is only when the function is called that the type of 
>>> receiver determines whether the passed struct is a pointer or a copied 
>>> value. But when using a function pointer, why does it decide whether to 
>>> bind a pointer or a copied value at the time of assignment, but not at the 
>>> time of function called? 
>>>
>>>
>> Neither is true.
>>
>> In go, *all* arguments are passed by value.  If the argument is a struct, 
>> then the struct is copied.  If the argument is a pointer, then the pointer 
>> is copied.
>>
>> Ignoring methods for a moment, just consider these simple functions:
>>
>> func Display1(z Zoo) { ... }
>> func Display2(z *Zoo) { ... }
>>
>> v := Zoo{}
>> Display1(v)   # v is copied
>> vp := 
>> Display2(vp)  # vp is copied
>>
>> These are identical, consistent behaviours.
>>
>> So now onto "pointer to function".  You are thinking like C.  In Go there 
>> is no meaningful "pointer to function", there are just "function values":
>> https://play.golang.org/p/Q6GogYU8f
>>
>> Internally of course, a function value will contain some sort of pointer 
>> to the code, just as a string value contains a pointer to the string, and a 
>> slice value contains a pointer to the slice backing array. (In the latter 
>> two cases the pointer may be nil if the len or cap is zero, and the overall 
>> value is still valid).  When you pass a string or a slice to a function, 
>> you are copying this structure with its embedded pointer/len/cap,  These 
>> pointers are implementation details, and are not directly accessible to the 
>> user program - at least not in a "safe" way.
>>
>> Whether the function takes zero arguments, one or more arguments, whether 
>> those arguments are structs or pointers or chans or whatever, affects the 
>> *type* of the value and hence how you call it, but otherwise a function 
>> value is just a value.
>>
>> So finally we get to methods:
>> https://play.golang.org/p/TAPCwDvxxbo
>>
>> If you take a method value (pf := gz.Display), you are just getting a 
>> function value, where the special first argument of the function has been 
>> bound ("curried") to some value.
>>
>> If the method takes a "Zoo" receiver, then the value is bound to a copy 
>> of the Zoo value.  If the method takes a "*Zoo" receiver, then the value is 
>> bound to a copy of the pointer-to-Zoo value.  Again, this is 100% 
>> consistent.  The function always receives a copy of the value, of the type 
>> of the argument.
>>
>> There is just one bit of magic, which is the automatic referencing and 
>> dereferencing.  Very roughly speaking: if a method takes a *Zoo but you 
>> apply it to a Zoo value, or vice versa, the value is converted from Zoo to 
>> pointer-to-Zoo or vice versa as required.
>>
>> But the value which is received by the method is always of the type it 
>> declares: func (z Zoo) Display() always takes a copy of a Zoo value, and 
>> func (z *Zoo) Display() always takes a copy of a pointer-to-Zoo value.  The 
>> value is always copied, and this is done at the time the method value is 
>> created, not the time at which it is called (which may be never, or may be 
>> many times).
>>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/dc60e8c5-1d48-4ce1-8181-1557f0db3a65n%40googlegroups.com.

Re: [go-nuts] gofmt error formatting suggestion

[Sean Liao]

proposed and declined: https://golang.org/issue/27450

On Wednesday, August 11, 2021 at 11:53:54 AM UTC+2 Ralph Seichter wrote:

> * burak serdar:
>
> > f, err:=os.Open(file); if err!=nil { return err }
>
> I see no advantage in this kind of formatting. Having separate
> statements on separate lines (instead of chained with ';') makes
> code easier to read, IMO.
>
> -Ralph
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e02a429a-42ce-4e7b-b2fe-baf1ddcb6a06n%40googlegroups.com.

Re: [go-nuts] The behavior of the function variable which points to the struct method

[E Z]

Thank you so much. 

Your explanation makes my understanding of this problem more and more clear.

However, since I have been a C programmer for a long time, I still don't 
understand the implementation of the function variable in Golang very well. 
I think I need to do some inspection about function variable in Golang to 
know more details.

On Wednesday, August 11, 2021 at 1:23:44 AM UTC-7 Brian Candler wrote:

> On Tuesday, 10 August 2021 at 22:50:00 UTC+1 lege...@gmail.com wrote:
>
>> And I'm still a little confused here, you know when we use the struct 
>> method directly, it is only when the function is called that the type of 
>> receiver determines whether the passed struct is a pointer or a copied 
>> value. But when using a function pointer, why does it decide whether to 
>> bind a pointer or a copied value at the time of assignment, but not at the 
>> time of function called? 
>>
>>
> Neither is true.
>
> In go, *all* arguments are passed by value.  If the argument is a struct, 
> then the struct is copied.  If the argument is a pointer, then the pointer 
> is copied.
>
> Ignoring methods for a moment, just consider these simple functions:
>
> func Display1(z Zoo) { ... }
> func Display2(z *Zoo) { ... }
>
> v := Zoo{}
> Display1(v)   # v is copied
> vp := 
> Display2(vp)  # vp is copied
>
> These are identical, consistent behaviours.
>
> So now onto "pointer to function".  You are thinking like C.  In Go there 
> is no meaningful "pointer to function", there are just "function values":
> https://play.golang.org/p/Q6GogYU8f
>
> Internally of course, a function value will contain some sort of pointer 
> to the code, just as a string value contains a pointer to the string, and a 
> slice value contains a pointer to the slice backing array. (In the latter 
> two cases the pointer may be nil if the len or cap is zero, and the overall 
> value is still valid).  When you pass a string or a slice to a function, 
> you are copying this structure with its embedded pointer/len/cap,  These 
> pointers are implementation details, and are not directly accessible to the 
> user program - at least not in a "safe" way.
>
> Whether the function takes zero arguments, one or more arguments, whether 
> those arguments are structs or pointers or chans or whatever, affects the 
> *type* of the value and hence how you call it, but otherwise a function 
> value is just a value.
>
> So finally we get to methods:
> https://play.golang.org/p/TAPCwDvxxbo
>
> If you take a method value (pf := gz.Display), you are just getting a 
> function value, where the special first argument of the function has been 
> bound ("curried") to some value.
>
> If the method takes a "Zoo" receiver, then the value is bound to a copy of 
> the Zoo value.  If the method takes a "*Zoo" receiver, then the value is 
> bound to a copy of the pointer-to-Zoo value.  Again, this is 100% 
> consistent.  The function always receives a copy of the value, of the type 
> of the argument.
>
> There is just one bit of magic, which is the automatic referencing and 
> dereferencing.  Very roughly speaking: if a method takes a *Zoo but you 
> apply it to a Zoo value, or vice versa, the value is converted from Zoo to 
> pointer-to-Zoo or vice versa as required.
>
> But the value which is received by the method is always of the type it 
> declares: func (z Zoo) Display() always takes a copy of a Zoo value, and 
> func (z *Zoo) Display() always takes a copy of a pointer-to-Zoo value.  The 
> value is always copied, and this is done at the time the method value is 
> created, not the time at which it is called (which may be never, or may be 
> many times).
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/6c1421bf-d16d-4b18-9117-91b286c95e76n%40googlegroups.com.

[go-nuts] Re: Is there a workflow engine written in GO

[Matt Bragaw]

GitHub - uber/cadence: Cadence is a distributed, scalable, durable, and 
highly available orchestration engine to execute asynchronous long-running 
business logic in a scalable and resilient way. 


On Thursday, October 26, 2017 at 6:56:40 AM UTC-7 nma...@gmail.com wrote:

> Hi Samuel,
>
> SciPipe looks pretty interesting. Maybe you could post about it in the Flow 
> Based Programming group 
> .
>
>
> On Wednesday, October 25, 2017 at 2:45:33 PM UTC-4, Samuel Lampa wrote:
>>
>> You might want to check out http://scipipe.org
>>
>> We developed it and are currently using it to run cheminformatics 
>> pipelines (data mangling, machine learning etc) on a HPC cluster, at 
>> http://pharmb.io  at Uppsala University.
>>
>> Cheers
>> // Samuel 
>>
>> On Friday, May 8, 2015 at 2:30:20 PM UTC+2, Sriram Jagadeesan wrote:
>>>
>>> I am trying to automated tasks( mainly server task with command line 
>>> process).
>>> I am looking for workflow engine if anything written in GOlang, which 
>>> could be used ?.
>>> There were some BPM workflow engines, but not suited for command line 
>>> server operations.
>>>
>>> Any input is high appreciated
>>>
>>> /Sriram.J 
>>>
>>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c17f5fb4-11a3-4a11-a3d8-dae5d49fd54bn%40googlegroups.com.

[go-nuts] 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?

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/350c23da-a352-4338-9341-cbab16d47f41n%40googlegroups.com.

Re: [go-nuts] gofmt error formatting suggestion

[Ralph Seichter]

* burak serdar:

> f, err:=os.Open(file); if err!=nil { return err }

I see no advantage in this kind of formatting. Having separate
statements on separate lines (instead of chained with ';') makes
code easier to read, IMO.

-Ralph

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/87lf58e29g.fsf%40wedjat.horus-it.com.

Re: [go-nuts] The behavior of the function variable which points to the struct method

[Brian Candler]

On Wednesday, 11 August 2021 at 09:23:44 UTC+1 Brian Candler wrote:

> v := Zoo{}
> Display1(v)   # v is copied
> vp := 
> Display2(vp)  # vp is copied
>
>
Correction: vp :=   or  vp := {...}
 

> These are identical, consistent behaviours.
>
> So now onto "pointer to function".  You are thinking like C.  In Go there 
> is no meaningful "pointer to function", there are just "function values":
> https://play.golang.org/p/Q6GogYU8f
>
>
Correction: that got mangled in copy-paste, it should say
https://play.golang.org/p/Q6GogYU8fLL

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2e879bc2-b208-4ddc-b0ca-55fb7829b453n%40googlegroups.com.

Re: [go-nuts] The behavior of the function variable which points to the struct method

[Brian Candler]

On Tuesday, 10 August 2021 at 22:50:00 UTC+1 lege...@gmail.com wrote:

> And I'm still a little confused here, you know when we use the struct 
> method directly, it is only when the function is called that the type of 
> receiver determines whether the passed struct is a pointer or a copied 
> value. But when using a function pointer, why does it decide whether to 
> bind a pointer or a copied value at the time of assignment, but not at the 
> time of function called? 
>
>
Neither is true.

In go, *all* arguments are passed by value.  If the argument is a struct, 
then the struct is copied.  If the argument is a pointer, then the pointer 
is copied.

Ignoring methods for a moment, just consider these simple functions:

func Display1(z Zoo) { ... }
func Display2(z *Zoo) { ... }

v := Zoo{}
Display1(v)   # v is copied
vp := 
Display2(vp)  # vp is copied

These are identical, consistent behaviours.

So now onto "pointer to function".  You are thinking like C.  In Go there 
is no meaningful "pointer to function", there are just "function values":
https://play.golang.org/p/Q6GogYU8f

Internally of course, a function value will contain some sort of pointer to 
the code, just as a string value contains a pointer to the string, and a 
slice value contains a pointer to the slice backing array. (In the latter 
two cases the pointer may be nil if the len or cap is zero, and the overall 
value is still valid).  When you pass a string or a slice to a function, 
you are copying this structure with its embedded pointer/len/cap,  These 
pointers are implementation details, and are not directly accessible to the 
user program - at least not in a "safe" way.

Whether the function takes zero arguments, one or more arguments, whether 
those arguments are structs or pointers or chans or whatever, affects the 
*type* of the value and hence how you call it, but otherwise a function 
value is just a value.

So finally we get to methods:
https://play.golang.org/p/TAPCwDvxxbo

If you take a method value (pf := gz.Display), you are just getting a 
function value, where the special first argument of the function has been 
bound ("curried") to some value.

If the method takes a "Zoo" receiver, then the value is bound to a copy of 
the Zoo value.  If the method takes a "*Zoo" receiver, then the value is 
bound to a copy of the pointer-to-Zoo value.  Again, this is 100% 
consistent.  The function always receives a copy of the value, of the type 
of the argument.

There is just one bit of magic, which is the automatic referencing and 
dereferencing.  Very roughly speaking: if a method takes a *Zoo but you 
apply it to a Zoo value, or vice versa, the value is converted from Zoo to 
pointer-to-Zoo or vice versa as required.

But the value which is received by the method is always of the type it 
declares: func (z Zoo) Display() always takes a copy of a Zoo value, and 
func (z *Zoo) Display() always takes a copy of a pointer-to-Zoo value.  The 
value is always copied, and this is done at the time the method value is 
created, not the time at which it is called (which may be never, or may be 
many times).

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/34c3fc58-4bdf-4dc0-bd13-a675be4d0f29n%40googlegroups.com.