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 langua

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 for

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

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 witho

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 unsubs

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 Mo

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) 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 p