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

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, 2

[go-nuts] JWZ Email Threading algorithm now available

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 wi

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

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:

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

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 exp

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

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 defaul

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

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 -

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

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

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

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

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

> 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

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

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

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

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 g

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

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

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

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

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

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,

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

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/issue

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

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 examp

Re: [go-nuts] gofmt error formatting suggestion

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 line

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

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 functi

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

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

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

// 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=

Re: [go-nuts] gofmt error formatting suggestion

* 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 Go

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

On Wednesday, 11 August 2021 at 09:23:44 UTC+1 Brian Candler wrote: > v := Zoo{} > Display1(v) # v is copied > vp := &Zoo > Display2(vp) # vp is copied > > Correction: vp := &v or vp := &Zoo{...} > These are identical, consistent behaviours. > > So now onto "pointer to function". You

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

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