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

2020-08-31 Thread samir.el...@gmail.com
Great improvements. Well done. Any intentions of making methods accept additional type arguments ? On Wednesday, August 26, 2020 at 1:54:49 PM UTC+2 Alan Donovan wrote: > On Wed, 26 Aug 2020 at 04:31, Denis Cheremisov > wrote: > >> > possibility of using angle brackets >> >> Please stop >> >>

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

2020-08-26 Thread 'Alan Donovan' via golang-nuts
On Wed, 26 Aug 2020 at 04:31, Denis Cheremisov wrote: > > possibility of using angle brackets > > Please stop > >- call these operator signs “brackets” >- pretending they are good in a role of brackets — they are not >- spreading this nonsense from C syntax family of languages to sane

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

2020-08-26 Thread Denis Cheremisov
> possibility of using angle brackets Please stop - call these operator signs “brackets” - pretending they are good in a role of brackets — they are not - spreading this nonsense from C syntax family of languages to saner once — yes, you heard it right. C is known for its chaotic de

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

2020-08-25 Thread Frederik Zipp
Ian Lance Taylor schrieb am Dienstag, 25. August 2020 um 00:35:33 UTC+2: > I've seen objections that a language change for generics should not > implicitly pull in a change to non-generic code. That seems fair. It > may be the right thing to do, but it should be justified separately. > So we're

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

2020-08-25 Thread Kaveh Shahbazian
I am excited about sum-types as much as generics themselves. Also, it's nice that any is a keyword restricted to be used inside the type parameter declaration as a type constraint. Very nice! --- P.S. Of-course now the proposal seems to go with brackets. Nevertheless, I wrote this comment <

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

2020-08-24 Thread Ian Lance Taylor
On Thu, Aug 20, 2020 at 9:54 PM Ian Lance Taylor wrote: > > Our intent here is that "any" will be available for all code. Yes, we > wouldn't do it if it weren't for its use as a type constraint. But if > we are going to do it for type constraints, there seems to be little > benefit to restrictin

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

2020-08-22 Thread Awh6al
This is absolutely big improvement to make go generics simple and remove the gap between the old and new syntax :). On Saturday, August 22, 2020 at 1:23:34 PM UTC+1 vkojo...@gmail.com wrote: > On Saturday, August 22, 2020 at 12:49:21 AM UTC+2 rog wrote: > >> On Fri, 21 Aug 2020 at 23:12, jimmy

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

2020-08-22 Thread Viktor Kojouharov
On Saturday, August 22, 2020 at 12:49:21 AM UTC+2 rog wrote: > On Fri, 21 Aug 2020 at 23:12, jimmy frasche wrote: > >> I don't want a generic min unless it looks like this: >> >> func Min[T constraints.Ordered](a, b T) T { >> switch T { >> case float32: >> return T(math.Min(float32(a),

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

2020-08-22 Thread Volker Dobler
On Friday, 21 August 2020 20:15:46 UTC+2, burak serdar wrote: > > [...] > I don't see why anybody would find it attractive as a return type. People > don't use the empty interface because they like it so much, but because Go > doesn't have parametric polymorphism / "generics" yet. There are man

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

2020-08-21 Thread Ian Lance Taylor
On Fri, Aug 21, 2020 at 3:03 PM Axel Wagner wrote: > > On Fri, Aug 21, 2020 at 11:46 PM Ian Lance Taylor wrote: >> >> Yes, there are various such possibilities. >> >> What jimmy frasche said above is correct: nothing changes in the case >> of a type switch of a type parameter. The code now knows

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

2020-08-21 Thread roger peppe
On Fri, 21 Aug 2020 at 23:12, jimmy frasche wrote: > I don't want a generic min unless it looks like this: > > func Min[T constraints.Ordered](a, b T) T { > switch T { > case float32: > return T(math.Min(float32(a), float32(b))) > case float64: > return T(math.Min(float64(a), float6

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

2020-08-21 Thread roger peppe
On Fri, 21 Aug 2020 at 23:03, Axel Wagner wrote: > On Fri, Aug 21, 2020 at 11:46 PM Ian Lance Taylor wrote: > >> Yes, there are various such possibilities. >> >> What jimmy frasche said above is correct: nothing changes in the case >> of a type switch of a type parameter. The code now knows the

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

2020-08-21 Thread roger peppe
On Fri, 21 Aug 2020 at 22:46, Ian Lance Taylor wrote: > Yes, there are various such possibilities. > > What jimmy frasche said above is correct: nothing changes in the case > of a type switch of a type parameter. The code now knows the type > list element that the type argument matched, but it c

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

2020-08-21 Thread jimmy frasche
I don't want a generic min unless it looks like this: func Min[T constraints.Ordered](a, b T) T { switch T { case float32: return T(math.Min(float32(a), float32(b))) case float64: return T(math.Min(float64(a), float64(b))) } if a < b { return a } return b } On Fri, Aug 2

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

2020-08-21 Thread 'Axel Wagner' via golang-nuts
On Fri, Aug 21, 2020 at 11:46 PM Ian Lance Taylor wrote: > Yes, there are various such possibilities. > > What jimmy frasche said above is correct: nothing changes in the case > of a type switch of a type parameter. The code now knows the type > list element that the type argument matched, but i

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

2020-08-21 Thread Bakul Shah
On Aug 21, 2020, at 2:07 PM, roger peppe wrote: > > Here's one interesting implication of this: it allows us to do type > conversions that were not previously possible. > > For example, if we have "type I int", we can use a type switch to convert > some type []I to type []int: > https://go2gop

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

2020-08-21 Thread Ian Lance Taylor
Yes, there are various such possibilities. What jimmy frasche said above is correct: nothing changes in the case of a type switch of a type parameter. The code now knows the type list element that the type argument matched, but it can't do anything that it couldn't do anyhow. Ian On Fri, Aug 21

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

2020-08-21 Thread 'Axel Wagner' via golang-nuts
also, of course, you could still use operators with them, while now also knowing the exact semantics of those operators (e.g. in regards to overflow), which might also be useful. On Fri, Aug 21, 2020 at 11:42 PM Axel Wagner wrote: > > > On Fri, Aug 21, 2020 at 11:30 PM roger peppe wrote: > >> O

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

2020-08-21 Thread 'Axel Wagner' via golang-nuts
On Fri, Aug 21, 2020 at 11:30 PM roger peppe wrote: > On Fri, 21 Aug 2020 at 22:10, jimmy frasche > wrote: > >> I'd assume that would fail to compile as you're returning a []T not a >> []int >> > > If that's the case, then I'm not sure that such a type switch would be > very useful. It would tel

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

2020-08-21 Thread roger peppe
On Fri, 21 Aug 2020 at 22:10, jimmy frasche wrote: > I'd assume that would fail to compile as you're returning a []T not a []int > If that's the case, then I'm not sure that such a type switch would be very useful. It would tell you what type the values are, but you can't do anything with them b

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

2020-08-21 Thread jimmy frasche
I'd assume that would fail to compile as you're returning a []T not a []int On Fri, Aug 21, 2020 at 2:07 PM roger peppe wrote: > > > On Fri, 21 Aug 2020 at 01:28, Ian Lance Taylor wrote: >> >> After many discussions and reading many comments, we plan to move >> forward with some changes and clar

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

2020-08-21 Thread roger peppe
On Fri, 21 Aug 2020 at 01:28, Ian Lance Taylor wrote: > After many discussions and reading many comments, we plan to move > forward with some changes and clarifications to the generics design > draft. > > 1. > > We’re going to settle on square brackets for the generics syntax. > We’re going to dr

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

2020-08-21 Thread Russ Cox
Hi all, A few people have raised concerns about "encouraging" use of any instead of interface{}, on the grounds that it is not idiomatic Go. I just wanted to acknowledge that yes, it's not idiomatic Go today, but that's true of essentially every language change. Thinking about future usage is a go

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

2020-08-21 Thread Russ Cox
On Fri, Aug 21, 2020 at 1:30 PM 'Axel Wagner' via golang-nuts < golang-nuts@googlegroups.com> wrote: > My one concern with making it an alias is error messages. > If the source code says "any", I think so should the error messages. > Currently, the compiler forgets aliases too early >

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

2020-08-21 Thread Viktor Kojouharov
I like all points in the draft change. My 2 cents around the any alias would be that it shouldn't be a problem. I don't think people are suddently going to start overusing it, since using vaues of type `interface{}` is extremely tedious in Go, and that won't magically change if the type is shor

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

2020-08-21 Thread burak serdar
On Fri, Aug 21, 2020 at 11:01 AM 'Carla Pfaff' via golang-nuts wrote: > > 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. "an

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

2020-08-21 Thread Denis Cheremisov
BTW, I am really glad your proposal is accepted, now the whole thing feels polished and IMO it is time to start building an implementation. пятница, 21 августа 2020 г. в 20:02:17 UTC+3, Carla Pfaff: > On Friday, 21 August 2020 at 16:46:22 UTC+2 bbse...@gmail.com wrote: > >> All constraints exce

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

2020-08-21 Thread roger peppe
On Fri, 21 Aug 2020 at 18:30, Axel Wagner wrote: > My one concern with making it an alias is error messages. > If the source code says "any", I think so should the error messages. > Currently, the compiler forgets aliases too early > . > I agree that's a co

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

2020-08-21 Thread 'Axel Wagner' via golang-nuts
My one concern with making it an alias is error messages. If the source code says "any", I think so should the error messages. Currently, the compiler forgets aliases too early . On Fri, Aug 21, 2020 at 7:08 PM roger peppe wrote: > > > On Fri, 21 Aug 2020 a

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

2020-08-21 Thread Jan Mercl
On Fri, Aug 21, 2020, 19:01 'Carla Pfaff' via golang-nuts < golang-nuts@googlegroups.com> wrote: People don't use the empty interface because they like it so much, but because Go doesn't have parametric polymorphism / "generics" yet. This argument seems to fail the fmt.Printf and friends reality

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

2020-08-21 Thread roger peppe
On Fri, 21 Aug 2020 at 15:24, Ian Lance Taylor wrote: > On Fri, Aug 21, 2020, 12:37 AM 'Axel Wagner' via golang-nuts < > golang-nuts@googlegroups.com> wrote: > >> Just to clarify, the intent is to make the declaration in the spec `type >> any = interface{}`, not `type any interface{}`, correct? T

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 burak serdar
On Fri, Aug 21, 2020 at 7:43 AM 'Carla Pfaff' via golang-nuts wrote: > > 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{}, w

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

2020-08-21 Thread roger peppe
On Fri, 21 Aug 2020 at 01:28, Ian Lance Taylor wrote: > After many discussions and reading many comments, we plan to move > forward with some changes and clarifications to the generics design > draft. > > 1. > > We’re going to settle on square brackets for the generics syntax. > We’re going to dr

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

2020-08-21 Thread Ian Lance Taylor
On Thu, Aug 20, 2020, 11:22 PM Bakul Shah wrote: > On Aug 20, 2020, at 5:27 PM, Ian Lance Taylor wrote: > > > 3. > > > > We’re going to clarify that when considering the operations permitted > > for a value whose type is a type parameter, we will ignore the methods > > of any types in the type l

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

2020-08-21 Thread Ian Lance Taylor
On Fri, Aug 21, 2020, 12:37 AM 'Axel Wagner' via golang-nuts < golang-nuts@googlegroups.com> wrote: > Just to clarify, the intent is to make the declaration in the spec `type > any = interface{}`, not `type any interface{}`, correct? The latter would > be more analogous to `error`. Either has cert

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 means

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

2020-08-21 Thread burak serdar
On Thu, Aug 20, 2020 at 11:54 PM Kurtis Rader wrote: > > On Thu, Aug 20, 2020 at 10:40 PM burak serdar wrote: >> >> What worries me is code like this: >> >> func f() any { >>int *i >> return i >> } >> >> func main() { >>if f()==nil { >> ... >>} >> } >> >> Use of "any" makes it l

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

2020-08-21 Thread David Riley
On Aug 21, 2020, at 00:56, Ian Lance Taylor wrote: > > No, the intent is that you would switch on the type parameter itself, > not a value. > > func g[T C](v T) T { > switch T { >// the rest is the same > } > } > > Thanks for asking. Oh, this clarifies my remaining murkiness about the ty

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

2020-08-21 Thread 'Axel Wagner' via golang-nuts
Just to clarify, the intent is to make the declaration in the spec `type any = interface{}`, not `type any interface{}`, correct? The latter would be more analogous to `error`. Either has certain advantages and disadvantages, I'm not sure which I prefer, but I just want to make sure I understand th

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

2020-08-20 Thread Bakul Shah
On Aug 20, 2020, at 5:27 PM, Ian Lance Taylor wrote: > > After many discussions and reading many comments, we plan to move > forward with some changes and clarifications to the generics design > draft. > > 1. > > We’re going to settle on square brackets for the generics syntax. > We’re going to

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

2020-08-20 Thread Kurtis Rader
On Thu, Aug 20, 2020 at 10:53 PM Kurtis Rader wrote: > Isn't your example just a case of confusing a nil interface with a nil > value inside a generic interface? How does requiring writing it as `func > f() interface{} {` make the behavior any clearer? > And the, possibly canonical, discussion a

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

2020-08-20 Thread Kurtis Rader
On Thu, Aug 20, 2020 at 10:40 PM burak serdar wrote: > What worries me is code like this: > > func f() any { >int *i > return i > } > > func main() { >if f()==nil { > ... >} > } > > Use of "any" makes it look like f returns an *int and f() is nil, but > it is not, because "any"

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

2020-08-20 Thread burak serdar
On Thu, Aug 20, 2020 at 10:54 PM Ian Lance Taylor wrote: > > On Thu, Aug 20, 2020 at 8:52 PM burak serdar wrote: > > > > On Thu, Aug 20, 2020 at 8:22 PM Jan Mercl <0xj...@gmail.com> wrote: > > > > > > On Fri, Aug 21, 2020 at 2:28 AM Ian Lance Taylor wrote: > > > > > > > To simplify the common ca

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

2020-08-20 Thread Ian Lance Taylor
On Thu, Aug 20, 2020 at 8:28 PM jimmy frasche wrote: > > To clarify on the type switches, would it have to be used like this: > > type C interface { > type X, Y > } > > func f(x X) X { > return x > } > > func g[T C](v T) T { > switch v { > case X: > // to use v as an X > // we must

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

2020-08-20 Thread Ian Lance Taylor
On Thu, Aug 20, 2020 at 8:52 PM burak serdar wrote: > > On Thu, Aug 20, 2020 at 8:22 PM Jan Mercl <0xj...@gmail.com> wrote: > > > > On Fri, Aug 21, 2020 at 2:28 AM Ian Lance Taylor wrote: > > > > > To simplify the common case of a type parameter that has > > > no constraints, we will introduce a

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

2020-08-20 Thread burak serdar
On Thu, Aug 20, 2020 at 8:22 PM Jan Mercl <0xj...@gmail.com> wrote: > > On Fri, Aug 21, 2020 at 2:28 AM Ian Lance Taylor wrote: > > > To simplify the common case of a type parameter that has > > no constraints, we will introduce a new predeclared identifier “any” > > as an alias for “interface{}”.

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

2020-08-20 Thread jimmy frasche
To clarify on the type switches, would it have to be used like this: type C interface { type X, Y } func f(x X) X { return x } func g[T C](v T) T { switch v { case X: // to use v as an X // we must convert x0 := X(v) x1 := f(x0) // to use x1 as a T // we must conv

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

2020-08-20 Thread Robert Engels
I like it. Well done. > On Aug 20, 2020, at 9:22 PM, Jan Mercl <0xj...@gmail.com> wrote: > > On Fri, Aug 21, 2020 at 2:28 AM Ian Lance Taylor wrote: > >> To simplify the common case of a type parameter that has >> no constraints, we will introduce a new predeclared identifier “any” >> as an a

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

2020-08-20 Thread Jan Mercl
On Fri, Aug 21, 2020 at 2:28 AM Ian Lance Taylor wrote: > To simplify the common case of a type parameter that has > no constraints, we will introduce a new predeclared identifier “any” > as an alias for “interface{}”. Anyone can write the declaration type any = interface{} today and p

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

2020-08-20 Thread David Riley
On Aug 20, 2020, at 20:27, Ian Lance Taylor wrote: > > 1. > > We’re going to settle on square brackets for the generics syntax. > We’re going to drop the “type” keyword before type parameters, as > using square brackets is sufficient to distinguish the type parameter > list from the ordinary par

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

2020-08-20 Thread Ian Lance Taylor
After many discussions and reading many comments, we plan to move forward with some changes and clarifications to the generics design draft. 1. We’re going to settle on square brackets for the generics syntax. We’re going to drop the “type” keyword before type parameters, as using square brackets