Re: [go-nuts] Alternate syntax for Go2 generics and contracts

2018-09-02 Thread Scott Cotton
Hi all, I just found out that there is a wiki for this kind of discussion, looks to me like a better venue, more organised, more interest, and just recently proposed on golang.org. Scott On Sunday, 2 September 2018 10:09:43 UTC+2, Tri

Re: [go-nuts] Alternate syntax for Go2 generics and contracts

2018-09-02 Thread Tristan Colgate
Just read: https://emilymaier.net/words/getting-specific-about-generics/ I think I concur, keep specification of behaviour in interfaces if possible. Contracts overlap too much. If interfaces can do the job, all be it less elegantly, the extra verbosity seems worth it to avoid the feature overla

Re: [go-nuts] Alternate syntax for Go2 generics and contracts

2018-09-01 Thread roger peppe
FWIW I've published some ideas about how contracts and interface types could be partially unified, and contracts significantly simplified, which I think is quite pertinent to the above discussion. Doc here: https://gist.github.com/rogpeppe/45f5a7578507989ec4ba5ac639ae2c69 On 1 September 2018 a

Re: [go-nuts] Alternate syntax for Go2 generics and contracts

2018-09-01 Thread Scott Cotton
On Saturday, 1 September 2018 20:29:31 UTC+2, Axel Wagner wrote: > > I don't understand what you are trying to say. You assert that there > wouldn't be a type-error, but you don't actually justify that. > There are 2 examples, both are (to me) intuitive suggestions and not the result of a phd

Re: [go-nuts] Alternate syntax for Go2 generics and contracts

2018-09-01 Thread 'Axel Wagner' via golang-nuts
I don't understand what you are trying to say. You assert that there wouldn't be a type-error, but you don't actually justify that. It seems pretty obvious to me, that if you instantiate my MultiReader example to, say, *strings.Reader, it would fail to compile. Because *multiReader is not a *string

Re: [go-nuts] Alternate syntax for Go2 generics and contracts

2018-09-01 Thread Scott Cotton
On Saturday, 1 September 2018 19:26:00 UTC+2, Scott Cotton wrote: > > > > On Saturday, 1 September 2018 18:26:29 UTC+2, Axel Wagner wrote: >> >> On Fri, Aug 31, 2018 at 6:57 PM Scott Cotton wrote: >> >>> My intuition is that interfaces would be obsolete -- and that's a very >>> good thing. >>>

Re: [go-nuts] Alternate syntax for Go2 generics and contracts

2018-09-01 Thread Scott Cotton
On Saturday, 1 September 2018 18:26:29 UTC+2, Axel Wagner wrote: > > On Fri, Aug 31, 2018 at 6:57 PM Scott Cotton > wrote: > >> My intuition is that interfaces would be obsolete -- and that's a very >> good thing. >> > > They wouldn't. You can't have heterogeneous lists with contracts. For > e

Re: [go-nuts] Alternate syntax for Go2 generics and contracts

2018-09-01 Thread 'Axel Wagner' via golang-nuts
On Fri, Aug 31, 2018 at 6:57 PM Scott Cotton wrote: > My intuition is that interfaces would be obsolete -- and that's a very > good thing. > They wouldn't. You can't have heterogeneous lists with contracts. For example, say you have a Reader contract: contract Reader(r R) { var ( n

Re: [go-nuts] Alternate syntax for Go2 generics and contracts

2018-08-31 Thread Scott Cotton
I think the draft is a very good start. In fact, there are many times when I find myself wondering whether to use interfaces when something like a contract in that draft is a more natural fit. I would encourage the authors to consider that math std lib package for float32 as a test case that w

Re: [go-nuts] Alternate syntax for Go2 generics and contracts

2018-08-31 Thread Daniela Petruzalek
I agree with Tristan in regards to orthogonality. Seeing the draft with all those complexities added to the language made me quite uneasy about this proposal. When I first started learning Go I was one of the first people to raise a hand and complain about the lack of generics in the language. Now

Re: [go-nuts] Alternate syntax for Go2 generics and contracts

2018-08-31 Thread Tristan Colgate
Also, and I think this probably applies to the existing syntax in the design. This example seems like a pathological use of generics. What would be the advantage over just declaring the function takes a Stringer? Am I missing something (presumably this is potentially avoids the interface call allo

Re: [go-nuts] Alternate syntax for Go2 generics and contracts

2018-08-31 Thread 'Axel Wagner' via golang-nuts
A contract can include multiple type parameters: https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md#mutually-referential-type-parameters AIUI your syntax can't cover that. And FWIW, I find the syntax of contracts in the doc far less "magic" than yours, but YMMV of course. O

[go-nuts] Alternate syntax for Go2 generics and contracts

2018-08-31 Thread Manlio Perillo
I just read the "official" proposal for Go2 generics and contracts. The current proposal makes the function syntax more complex, and the syntax for the contract is a bit magic. What about something like: type stringer template contract (x stringer) { var s string = x.String()