Re: [go-nuts] [ generics] Moving forward with the generics design draft

2020-08-21 Thread 'Carla Pfaff' via golang-nuts
On Friday, 21 August 2020 at 16:46:22 UTC+2 bbse...@gmail.com wrote: > All constraints except "any" specify a constraint for the type. A > Stringer constraint will ensure that the type has String() string > method. "any" is a lack of constraint. The empty interface / any is a constraint that

Re: [go-nuts] [ generics] Moving forward with the generics design draft

2020-08-21 Thread 'Carla Pfaff' via golang-nuts
On Friday, 21 August 2020 at 14:57:13 UTC+2 bbse...@gmail.com wrote: > interface{}, when used as a constraint, doesn't mean than the value > has to be an interface{}, it means the value can be anything. > interface{}, when used as a value, doesn't mean that the value can be > anything, it

Re: [go-nuts] Re: module confusion

2020-08-14 Thread 'Carla Pfaff' via golang-nuts
People and installers usually install Go in /usr/local/go on Unix-like systems. ~/go is the default GOPATH if not set, so ~/go/bin is where binaries installed via "go get" / "go install" land. But the Go distribution itself must not be under GOPATH. -- You received this message because you

[go-nuts] Re: module confusion

2020-08-14 Thread 'Carla Pfaff' via golang-nuts
This has nothing to do with modules. You're still using the old GOPATH mode, because you're not in a directory with a go.mod file. GOPATH defaults to $HOME/go when it's not set (since 1.8), but that's where you chose to put your Go installation. This is not allowed. Either install Go to a

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

2020-08-10 Thread 'Carla Pfaff' via golang-nuts
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] [proposal] Make go compiler work with different syntax versions in same project to support adaptivity

2020-08-10 Thread 'Carla Pfaff' via golang-nuts
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

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

2020-08-07 Thread 'Carla Pfaff' via golang-nuts
On Saturday, 8 August 2020 at 01:33:59 UTC+2 Patrick Smith wrote: > if we think it likely that a future version of Go will allow operator > overloading > That's highly unlikely: https://golang.org/doc/faq#overloading -- You received this message because you are subscribed to the Google

[go-nuts] Re: Modifying Source code and build go from the source.

2020-08-07 Thread 'Carla Pfaff' via golang-nuts
Well, it says "lock_futex.go:152:2: ns declared but not used". An unused variable is a compile error in Go. On Friday, 7 August 2020 at 09:54:23 UTC+2 Yosef Yo wrote: > /home/nn/Downloads/go/src/runtime/lock_futex.go:152:2: ns declared but not > used > > go tool dist: FAILED > -- You

Re: [go-nuts] A few thoughts on type parameters

2020-08-03 Thread 'Carla Pfaff' via golang-nuts
On Tuesday, 4 August 2020 at 00:34:12 UTC+2 ben...@gmail.com wrote: > Which at first seems like a good idea, but then unless "any" is built in > or this becomes a well-known idiom, it won't be as self-documenting. Other > people will have to look up the definition to see "oh, I see, this is

Re: [go-nuts] A few thoughts on type parameters

2020-08-03 Thread 'Carla Pfaff' via golang-nuts
On Monday, 3 August 2020 at 19:46:05 UTC+2 Ian Lance Taylor wrote: > Yet another possibility, going back to the syntax question above, is > requiring that a type parameter for a type alway have a constraint, > which would mean that we would never use the "type" keyword for type > parameters,

[go-nuts] Re: Why we don't have simple throws error statement

2020-08-01 Thread 'Carla Pfaff' via golang-nuts
Your "throws" statement (why is it called "throws" when it "catches" according to the comment?) looks a lot like the "handle" block from the first draft design by the Go team: the check/handle proposal . On

Re: [go-nuts] Re: [generics] Feedback on optional type keyword experiment

2020-07-25 Thread 'Carla Pfaff' via golang-nuts
On Sunday, 26 July 2020 at 07:06:16 UTC+2 Carla Pfaff wrote: > Maybe gofmt could rewrite "interface{}" to "any", so there won't even be > such a question for new code. > When I think about it, that's probably not possible for gofmt to do in a safe way. -- You received this message because

Re: [go-nuts] Re: [generics] Feedback on optional type keyword experiment

2020-07-25 Thread 'Carla Pfaff' via golang-nuts
On Sunday, 26 July 2020 at 03:13:30 UTC+2 Denis Cheremisov wrote: > The bad with *any* in builtins is there will be questions "why you use > interface{}" if there's builtin *any?*", etc. If Go has generics I expect that people will use "interface{}"/"any" a lot less outside of type parameter

Re: [go-nuts] Re: [generics] Feedback on optional type keyword experiment

2020-07-25 Thread 'Carla Pfaff' via golang-nuts
I don't see why it should be in the grammar. Just a regular type alias for interface{} in the builtin scope, a regular predeclared identifier. It wouldn't break anyone's code. If someone already has an 'any' type or variable in their package their version shadows the builtin one, and they can

Re: [go-nuts] Re: [generics] Feedback on optional type keyword experiment

2020-07-25 Thread 'Carla Pfaff' via golang-nuts
On Saturday, 25 July 2020 at 22:22:24 UTC+2 Ian Lance Taylor wrote: > Note that in this way constraints on type parameters are different > from types of regular parameters. It makes no sense to speak of a > regular parameter with no type. > In regular parameter lists interface{} has this role,

Re: [go-nuts] Re: [generics] Feedback on optional type keyword experiment

2020-07-25 Thread 'Carla Pfaff' via golang-nuts
QV5LTAIuDr > > On Saturday, 25 July 2020 at 22:22:24 UTC+2 Ian Lance Taylor wrote: > >> On Sat, Jul 25, 2020 at 11:47 AM 'Carla Pfaff' via golang-nuts >> wrote: >> > >> > To expand on my post: >> > It would be very consistent with the struc

Re: [go-nuts] Re: [generics] Feedback on optional type keyword experiment

2020-07-25 Thread 'Carla Pfaff' via golang-nuts
ng.org/p/IQV5LTAIuDr On Saturday, 25 July 2020 at 22:22:24 UTC+2 Ian Lance Taylor wrote: > On Sat, Jul 25, 2020 at 11:47 AM 'Carla Pfaff' via golang-nuts > wrote: > > > > To expand on my post: > > It would be very consistent with the structure of regular parameter > lists. J

[go-nuts] Re: [generics] Feedback on optional type keyword experiment

2020-07-25 Thread 'Carla Pfaff' via golang-nuts
To expand on my post: It would be very consistent with the structure of regular parameter lists. Just like every parameter in a regular parameter list must have a type (with the exception of multiple consecutive parameters having the same type), every type parameter in a type parameter list

[go-nuts] [generics] Feedback on optional type keyword experiment

2020-07-25 Thread 'Carla Pfaff' via golang-nuts
I just discovered the experiment to make the "type" keyword optional in certain cases on the dev.go2go branch. The commit message says: --- Experiment: Make "type" keyword optional in generic type declarations when it is clear that we can't have an array type declaration. This is the

[go-nuts] Re: [generics] Fuzzer, Type Switches

2020-07-17 Thread 'Carla Pfaff' via golang-nuts
Why not write two functions? On Friday, 17 July 2020 at 21:36:38 UTC+2 jrh...@gmail.com wrote: > I was playing around with trying to use generics to de-interface-ify a > fuzzer implementation, and I ran into some stumbling blocks. > > is it possible to perform type switches? It seems the answer

Re: [go-nuts] Re: Generics and parentheses

2020-07-16 Thread 'Carla Pfaff' via golang-nuts
On Thursday, 16 July 2020 at 22:44:21 UTC+2 jpap wrote: > I don't think [[T]] is offensive to the surrounding code, and would love > to know what more people think. > It becomes even worse once you nest generic types: MyMap[[string, MyList[[int -- You received this message because

Re: [go-nuts] Re: Generics and parentheses

2020-07-16 Thread 'Carla Pfaff' via golang-nuts
Generics are not the most important part of the language/code. Let's not make them stick out like a sore thumb. On Thursday, 16 July 2020 at 22:12:17 UTC+2 jpap wrote: > On Thursday, 16 July 2020 at 12:51:03 UTC-7 Ian Lance Taylor wrote: > >> On Thu, Jul 16, 2020 at 12:41 PM joshua harr wrote:

[go-nuts] Re: Generics and parentheses

2020-07-15 Thread 'Carla Pfaff' via golang-nuts
I really like this square bracket syntax and I'm glad that Go does not repeat the mistakes other languages have made.. -- 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

[go-nuts] Re: go.pkg.dev: blitznote.com/src/semver doesn't show up

2020-06-26 Thread 'Carla Pfaff' via golang-nuts
For me it is in the search results. Currently on page 5, fifth entry: https://pkg.go.dev/search?page=5=semver On Friday, 26 June 2020 at 21:47:30 UTC+2 Mark Kubacki wrote: > Hi, > > I've noticed my package, blitznote.com/src/semver, doesn't show up in > pkg.go.dev despite having been licensed