Re: [go-nuts] Re: [generics] How to use maps in generic structs?

Just a quick thought, instead of "comparable" (and type lists) maybe we could use a single operator to specify the required "operators" interface: type BiMap[type V, K ==] struct { forward map[K]V reverse map[V]K } func Max[type T <](a, b T) T { } func ScanRowStruct[type T .](rows sql.Rows,

[go-nuts] Re: [generics] How to use maps in generic structs?

The type of map keys in Go should be comparable. As you haven't specified any restriction to the type parameters, it doesn't compile because Go doesn't know whether K and V are comparable. If you add the restriction "comparable", then it compiles: type BiMap[type V, K comparable] struct {

Re: [go-nuts] [proposal] Make go compiler work with different syntax versions in same project to support adaptivity

On Monday, 10 August 2020 at 10:30:55 UTC+2 Ivan Ivanyuk wrote: > There is already an instrument in playground that works fine. Why not just > roll it out and improve design, if needed, in next version? > The go2go tool is just a toy, an experiment, a simple translation tool. It will be thrown

Re: [go-nuts] [proposal] Make go compiler work with different syntax versions in same project to support adaptivity

A handyman can do many things. But domain-specific experts like plumbers, electricians, and carpenters are far more skilled and efficient. Statistical analysis of psycholinguistics indicates that there exist specific modes of thinking, no one syntax will ever be the best syntax for all modes

[go-nuts] [generics] How to use maps in generic structs?

This is invalid: type BiMap[type V, K] struct { forward map[K]V reverse map[V]K } How do I specify an interface constraint for V,K such that this is valid? Is that possible at all? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To

Re: [go-nuts] Port to powerpc 440fpu

On Aug 10, 2020, at 4:59 AM, Hugo Cornelis wrote: > > > Hi, > > Bottom line: Docker works reliably on powerpc 440fpu 32 bit using gccgo as > the compiler. We will likely soon start working on powerpc e6500 in 32bit > mode. > > After a fix in the structures used by the epoll system calls,

Re: [go-nuts] Gollvm failed to build hugo

Hello, >># github.com/gohugoio/hugo >>/usr/bin/ld.gold: error: $WORK/b029/_pkg_.a(gccgo_c.o): failed to match split-stack sequence at section 1 offset 0 This issue is https://github.com/golang/go/issues/38728, which should be fixed at this point at tip. Thanks, Than On Mon, Jul 20, 2020 at

[go-nuts] Re: [generics] How to use maps in generic structs?

K and V must be comparable, since you use them as map keys: type BiMap[type V, K comparable] struct { forward map[K]V reverse map[V]K } -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails

Re: [go-nuts] [generics] Was "no type contracts" considered?

On Sun, Jul 19, 2020 at 3:16 AM Ian Lance Taylor wrote: > On Sat, Jul 18, 2020 at 4:55 AM Markus Heukelom > wrote: > > > > Concerning the current generics proposal, was it every considered to not > allow type contracts at all? > > > > No type contracts would mean that generic functions can only

[go-nuts] Re: "eg tool" for modules

There is a related issue , on Go GitHub repository, tracking support for modules. On Sunday, August 9, 2020 at 12:23:12 AM UTC+2 Kaveh Shahbazian wrote: > The "eg" tool - from Go Tools > Repo/Module - does not support

Re: [go-nuts] [generics] Was "no type contracts" considered?

On Mon, Aug 10, 2020 at 6:07 AM Markus Heukelom wrote: > > For what it is worth: for non-exported functions/types all operations could > be allowed, possibly leading to infamous C++-level error messages but as you > are the author of the package, those error messages would make sense to you >

Re: [go-nuts] Generics and parentheses

I am trying to add my 2 cents here. I am sorry if my opinions have been mentioned. I personally prefer Round Brackets (parentheses). It is not about readability on symbols, but the way how I understand the logic of Type Parameters. I see Type Parameters as a way to describe how to

Re: [go-nuts] Generics: after type lists

Another way to bridge the gap between builtin and custom types could be to have a package op that has functions that delegate to either an operator or a method. Then you could write generic functions like func Min[type T op.Lessable](a, b T) T { if op.Less(a, b) { return b } return a

Re: [go-nuts] Re: [generics] How to use maps in generic structs?

On Mon, Aug 10, 2020 at 7:08 AM Alvadron wrote: > > The type of map keys in Go should be comparable. As you haven't specified any > restriction to the type parameters, it doesn't compile because Go doesn't > know whether K and V are comparable. > > If you add the restriction "comparable", then

Re: [go-nuts] [proposal] Make go compiler work with different syntax versions in same project to support adaptivity

On Mon, Aug 10, 2020 at 1:30 AM Ivan Ivanyuk wrote: > > Thank you for answering > > Why does it take so long to implement generics then? There is already an > instrument in playground that works fine. Why not just roll it out and > improve design, if needed, in next version? > > Having generics

Re: [go-nuts] Re: [generics] How to use maps in generic structs?

On Mon, Aug 10, 2020 at 7:08 AM Markus Heukelom wrote: > > Just a quick thought, instead of "comparable" (and type lists) maybe we could > use a single operator to specify the required "operators" interface: > > type BiMap[type V, K ==] struct { > forward map[K]V > reverse map[V]K > } > > func

Re: [go-nuts] Generics: after type lists

On Mon, Aug 10, 2020 at 10:46 AM 'Richard Oudkerk' via golang-nuts wrote: > > Another way to bridge the gap between builtin and custom types could be to > have a package op that has functions that delegate to either an operator or a > method. Then you could write generic functions like > >

Re: [go-nuts] Generics: after type lists

On Mon, Aug 10, 2020 at 1:53 PM burak serdar wrote: > Would it be possible to make it explicit instead of trying to combine > builtin types and others? > > type Number interface { >type int, int8, int16, int32, int64, unit, int8, int16, int32, > uint64, float32, float64 > } > > func Min(type

Re: [go-nuts] [proposal] Make go compiler work with different syntax versions in same project to support adaptivity

Ok, thanks for the clarification. On Mon, Aug 10, 2020 at 9:38 PM Ian Lance Taylor wrote: > On Mon, Aug 10, 2020 at 1:30 AM Ivan Ivanyuk > wrote: > > > > Thank you for answering > > > > Why does it take so long to implement generics then? There is already an > instrument in playground that

Re: [go-nuts] Generics: after type lists

On Mon, Aug 10, 2020 at 9:46 AM 'Richard Oudkerk' via golang-nuts wrote: > Another way to bridge the gap between builtin and custom types could be to > have a package op that has functions that delegate to either an operator or a > method. Then you could write generic functions like > > func

Re: [go-nuts] [proposal] Make go compiler work with different syntax versions in same project to support adaptivity

Thank you for answering Why does it take so long to implement generics then? There is already an instrument in playground that works fine. Why not just roll it out and improve design, if needed, in next version? Having generics in 2021 means many projects will choose other languages in 2020,

Re: [go-nuts] Port to powerpc 440fpu

Hi, Bottom line: Docker works reliably on powerpc 440fpu 32 bit using gccgo as the compiler. We will likely soon start working on powerpc e6500 in 32bit mode. After a fix in the structures used by the epoll system calls, the problem disappeared. I assume the problem was a starvation similar to

Re: [go-nuts] Re: Dynamic include path in cgo?

Another possible course of action is to have all the logic of generating these lines embedded inside a 'go generate' program. That's what has been done in go-python/gopy for example. -s Original Message On Aug 10, 2020, 06:18, wrote: > On Sunday, August 9, 2020 at 9:56:43 AM