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 would be very demanding of the design in the proposal (and useful if realised). I would also encourage the authors to think about what the language would have looked like if it had contracts (as in the proposal) instead of interfaces from the start. My intuition is that interfaces would be obsolete -- and that's a very good thing. You could implement interface in terms of contract as some sort of bridge for compatibility. But if the proposal could come up with a way to extend the interface syntax with contract-like semantics, perhaps the overlap between the two could just disappear. As for the question in the proposal about implementation by interface or not (compilation speed vs execution speed), my own use cases often require re-thinking something without interfaces (like the heap in my sat solver) for performance. Here's a thumbs up for execution speed and hearty "go for it" for compiler writers to make it fast :) Nice work on the proposal. Scott On Friday, 31 August 2018 18:47:45 UTC+2, Daniela Petruzalek wrote: > > 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, a year later, after learning about Go proper > idioms, I strongly regret my previous stance. I was trying to make Go > another language that was not Go. I didn't want to learn to write idiomatic > Go code, I wanted to write Go in the same way I used to write C++ (for > instance). That was wrong on so many levels. > > I'm now sitting in the fence in regards to the generics addition to the > language. My previous arguments don't hold anymore. I like how the current > Go language forces our intentions to be explicit rather than hiding the > real code under some clever abstractions that few people understand. I feel > that I became a better programmer that way, thinking about the collective > before trying to please myself showing how smart I am. I feel it also > encourages collaboration since it's really easy to get an overall > understanding of the language. It's accessible for junior developers and > enthusiasts since there are fewer concepts to learn, yet they provide some > powerful abstractions. Look at the things that were built with Go... > Kubernetes, Docker... it's a really powerful language while still being > truthful to its simplified flow control, simplified (yet verbose) error > handling, simplified data structures... > > I strongly wish that a generics proposal would stay true to the Go's > simplicity principle, but I somehow don't feel this proposal does meet that > requirement at it's current state. > > Sorry to hijack the thread! > > Best, > > Dani > > Em sex, 31 de ago de 2018 às 10:54, Tristan Colgate <tcol...@gmail.com > <javascript:>> escreveu: > >> 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 >> allocation?). >> This is a good example of my gut feeling about generics, I realise >> they'll be valuable, but do they devalue interfaces? They do not seem like >> an orthogonal feature. Of the two, interfaces feel like they encourage me >> to write better structured code. >> This could also just be fear of change. >> >> >> On Fri, 31 Aug 2018 at 14:34 'Axel Wagner' via golang-nuts < >> golan...@googlegroups.com <javascript:>> wrote: >> >>> 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. >>> >>> On Fri, Aug 31, 2018 at 6:43 AM Manlio Perillo <manlio....@gmail.com >>> <javascript:>> wrote: >>> >>>> 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() >>>> } >>>> >>>> func Stringify(s []stringer) (ret []string) { >>>> for _, v := range s { >>>> ret = append(ret, v.String()) >>>> } >>>> return ret >>>> } >>>> >>>> instead of >>>> >>>> >>>> contract stringer(x T) { >>>> var s string = x.String() >>>> } >>>> >>>> func Stringify(type T stringer)(s []T) (ret []string) { >>>> for _, v := range s { >>>> ret = append(ret, v.String()) >>>> } >>>> return ret >>>> } >>>> >>>> >>>> Thanks >>>> Manlio >>>> >>>> -- >>>> 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 email to golang-nuts...@googlegroups.com <javascript:>. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> -- >>> 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 email to golang-nuts...@googlegroups.com <javascript:>. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> 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 >> email to golang-nuts...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > -- 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 email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
