[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

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

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
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
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] 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] 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 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:

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

[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: 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] 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,

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