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

Oops, I meant "all interfaces can be used as a constraint yet there are interfaces that can be used as a value's type" -- 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: [ generics] Moving forward with the generics design draft

> But I don't think that using type list constraint as sum types is good idea. > Type constraints should be known in compile-time, but the sum type variant should be known in run-time. It looks like you misunderstand it a bit. Indeed type Constraint interface { type Type₁, Type₂, …, Typeₙ

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

I'd like to see sum types in Go2 and there are many reasons: - It can make using oneOf/anyOf in protobuf or swagger mush easier. - It can make ast.Node type-safe. - With sum-types compiler known maximum size of variant, so it can be allocated on stack, not on heap. But I don't think that using

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

After thinking about this more last evening and reading code in the new style, I've changed my mind. I think my previous feedback was too influenced by the fact that I disliked a new predeclared identifier being introduced, and that the style was different from what I'm used to in TypeScript/Java.

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

On Wed, Sep 2, 2020 at 7:02 PM Nishanth Shanmugham < nishanth.gerr...@gmail.com> wrote: > If it is intended at simplification for parsers, […] If it is intended to > improve readability for readers of generic code > I would argue that this is not a dichotomy. On the contrary: In general, a

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

Some feedback on requiring any/interface{} explicitly. > We feel that the cost of the new predeclared identifier “any” is outweighed by the simplification achieved by making all parameter lists syntactically the same Why is this simplification preferred? If it is intended at simplification

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

On Mon, Aug 31, 2020 at 10:25 AM samir.el...@gmail.com wrote: > > Great improvements. Well done. > > Any intentions to make methods accept additional type arguments ? See https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#No-parameterized-methods . Ian

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

Great improvements. Well done. Any intentions to make methods accept additional type arguments ? On Friday, August 21, 2020 at 2:28:23 AM UTC+2 Ian Lance Taylor wrote: > After many discussions and reading many comments, we plan to move > forward with some changes and clarifications to the

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

On Thursday, 20 August 2020 20:28:23 UTC-4, Ian Lance Taylor wrote: > We’re going to settle on square brackets for the generics syntax. FWIW, the same square-bracket syntax was used by Barbara Liskov's CLU in the mid-1970s, and was, as far as I can tell, the first syntax used for parametric

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

On Mon, 24 Aug 2020 at 12:57, 'Richard Oudkerk' via golang-nuts < golang-nuts@googlegroups.com> wrote: > > Applying the same rule to type lists and type switches you should be able > to write > > type Comparer[T any] interface { > Compare(T) int > } > > type CompareConstraints

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

The current proposal says *The rule is that if a type contraint has a single type parameter, and it is used in a function's type parameter list

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

>> Could you please give an example of the proposed syntax? > func F[T constraints.Integer]() { > switch T { > case int: > case int8: > } > } Makes perfect sense, thanks. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To

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

I liked the 'any' idea. It always felt to me a bit odd/not so clear interface{} means anything. Still, interfaces with type parameters for non generic code seems a mix of behaviour and implementation description. In all, looking forward to see these changes implemented to try them out :) On

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

On Mon, 24 Aug 2020 at 06:35, Denis Cheremisov wrote: > I probably didn't read what you have wrote in the first message carefuly > enough. Does it mean something like that will work > > type SomeTypes interface { > type int, float32, float64 > } > > func Min[T SomeTypes](x, y T)

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

I probably didn't read what you have wrote in the first message carefuly enough. Does it mean something like that will work type SomeTypes interface { type int, float32, float64 } func Min[T SomeTypes](x, y T) T { switch T { case int: if x < y {

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

On Sun, Aug 23, 2020 at 3:00 PM Juliusz Chroboczek wrote: > > > We’re going to permit type switches on type parameters that have type > > lists, without the “.(type)” syntax. The “(.type)” syntax exists to > > clarify code like “switch v := x.(type)”. > > Could you please give an example of the

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

> We’re going to permit type switches on type parameters that have type > lists, without the “.(type)” syntax. The “(.type)” syntax exists to > clarify code like “switch v := x.(type)”. Could you please give an example of the proposed syntax? -- You received this message because you are

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

On 21-08-2020, Russ Cox wrote: > A few other people have raised concerns about not seeing the word interface > and therefore not realizing "any" is an interface type and potentially > getting confused. This is also a good consideration, but we already have > many interface types that don't use

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

I believe these are fantastic choices. I have given two presentations to Go meetups about the draft generics design in the last month. The second time was after the square bracket idea was added to the prototype and someone suggested the other parts adopted in item #1. In that second