> clear feedback on earlier versions of the design draft that contracts could be hard to understand.
Yeah, sure. Now expect lots of materials throughout the web explaining "this part is for interface that is not supposed to be in a runtime but for compile time constraints". You understand better than me albeit these concepts (interfaces and contractrs) has a lot in common they are not the same. At last, take your language as an example: it shines as a glue between services and its set of primitives (goroutines, channels, full async) is what made it so successful in this domain. But you won't try to use it for serious Linux kernel module. You won't even try these primitives for GUI development (which also has asynchronous nature) because they have a huge overweight for the task. PS I am afraid these people I were listening also want <> четверг, 18 июня 2020 г., 1:11:22 UTC+3 пользователь Ian Lance Taylor написал: > > On Wed, Jun 17, 2020 at 9:58 AM Denis Cheremisov > <[email protected] <javascript:>> wrote: > > > > IMO a groups of constraints are horrible with interfaces > > > > type CommonResponse(type E) interface { > > GetError() E > > } > > > > type CommonError interface { > > GetCode() int32 > > } > > > > func IsOK(type R CommonResponse(E), E CommonError)(r R) bool { > > switch r.GetError().GetCode() { > > case 0, 200, 201: > > return true > > default: > > return false > > } > > } > > > > vs > > > > constract CommmonResponse(R, E) { > > R GetError() E > > E GetCode() int32 > > } > > > > func IsOK(type R, E CommonResponse)(r R) bool { > > switch r.GetError().GetCode() { > > case 0, 200, 201: > > return true > > default: > > return false > > } > > } > > > > That trickery with commas to express dependcy of types is hard > > > I think there is no question that complex cases are more difficult to > express using parameterized interfaces as constraints. > > But the overall change to the language seems to be simpler. There was > clear feedback on earlier versions of the design draft that contracts > could be hard to understand. And with parameterized interfaces as > constraints it is still possible to express the complex cases, albeit > in a more complicated way. It's OK if complicated are hard to > express, as long as they remain possible. > > Ian > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/50d5375c-1698-4006-8888-9ac3a6c84d1do%40googlegroups.com.
