On Wed, Jun 17, 2020 at 9:58 AM Denis Cheremisov
<denis.cheremi...@gmail.com> 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 golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcV6xevZ8rB0%3DJHB-UTKsrGScgciCR-_hdzM5g1qh9CTFQ%40mail.gmail.com.
