Re: [go-nuts] [generics] cannot use generic type list.Element(type TElem) without instantiation

On Wed, Jul 1, 2020 at 8:22 PM Andrey T. wrote: > > continuation question -- does `type intElement list.Element(int)` introduce a > new type just like `type myInt int` does? If so, in a previous example, these > 2 maps are not of the same type, am I right? Yes, "type intElement list.Element(int

Re: [go-nuts] [generics] cannot use generic type list.Element(type TElem) without instantiation

Ian, continuation question -- does `type intElement list.Element(int)` introduce a new type just like `type myInt int` does? If so, in a previous example, these 2 maps are not of the same type, am I right? Thank you very much, Andrey On Wednesday, July 1, 2020 at 10:50:07 AM UTC-6, Ian Lance

Re: [go-nuts] draft design for // +build replacement

My suggestion was a variation on rsc's #2. Still a simple rule that is easy for people to remember and doesn't require asking the go command. Prefer a simple rule compared to any intermediation by a program. > On Jul 1, 2020, at 11:54 AM, jimmy frasche wrote: > > Running find -name "*_*.go" | xa

Re: [go-nuts] draft design for // +build replacement

Running find -name "*_*.go" | xargs grep " +build" on goroot shows a lot of files with redundant build tags or additional constraints not present in the file name so they don't seem like much of a single point of truth. I'd be fine with removing file names sometimes implying build tags. Add build

Re: [go-nuts] draft design for // +build replacement

4. Use two underscores for constraints. At least new constraints. Aside: Are you plantin' an idea about Plan10? > On Jul 1, 2020, at 11:06 AM, Russ Cox wrote: > > For what it's worth, I am (unsurprisingly) a big fan of the filename-based > constraints. It's a lightweight convention that has se

Re: [go-nuts] draft design for // +build replacement

For what it's worth, I am (unsurprisingly) a big fan of the filename-based constraints. It's a lightweight convention that has served us incredibly well. I really like being able to see in a directory listing which files go with what. It would be unfortunate if we had to put the redundant info insi

Re: [go-nuts] Why does PipeWriter.CloseWithError pretend to return an error?

On Wed, Jul 1, 2020 at 9:30 AM Glen Mailer wrote: > > We got bitten by a bug recently when using PipeWriter.CloseWithError. We > incorrectly assumed it would pass-through the error it was passed. > > The docs do say that it will always return `nil`, but does anyone know why it > has an `error` r

Re: [go-nuts] [generics] cannot use generic type list.Element(type TElem) without instantiation

On Wed, Jul 1, 2020 at 9:39 AM wrote: > > Is this expected? > > import "list" // for 'std' list.go2 > > func main() { > type intElement list.Element(int) > _ = make(map[int]intElement) // ok: compiles > > // nok > _ = make(map[int]list.Element(int)) // cannot use generic type > list.Element(type

[go-nuts] [generics] cannot use generic type list.Element(type TElem) without instantiation

Hi, Is this expected? import "list" // for 'std' list.go2 func main() { type intElement list.Element(int) _ = make(map[int]intElement) // ok: compiles // nok _ = make(map[int]list.Element(int)) // cannot use generic type list.Element(type TElem) without instantiation } I don't think it is, b

[go-nuts] Re: Bitstring package?

https://godoc.org/github.com/arl/evolve/pkg/bitstring I made this bitstring package some time ago while I was experimenting with genetic algorithms in go. I'm the only to use but I used it a lot, there are a bunch of tests/benchmarks. Feel free to use it Le mardi 30 juin 2020 03:59:27 UTC+2, ha

[go-nuts] Why does PipeWriter.CloseWithError pretend to return an error?

Hi everyone, We got bitten by a bug recently when using PipeWriter.CloseWithError . We incorrectly assumed it would pass-through the error it was passed. The docs do say that it will always return `nil`, but does anyone know why it has an `

[go-nuts] Re: run golang cpu profile for 5mins but only got 1.64mins (32.69%) samples

On Tuesday, 30 June 2020 18:16:54 UTC+2, lqiy...@gmail.com wrote: > > $ go version > go version go1.13.10 > > In the container, the golang process used 100% of the CPU. When I took a > 5minutes CPU profile, the result shows that only 1.64mins (32.69%) samples > are returned. Is it normal? > > go

Re: [go-nuts] draft design for // +build replacement

This might as well replace makefiles for testing and other tools. or similar formats. //go:test devenv func TestFoo(t *testing.T) {} //go:test devenv -failfast -short -cover ./... func TestFoo2(t *testing.T) {} //go:test prod func TestProduction(t *testing.T) {} $ go test devenv On Wed, Jul 1