On Friday, 2 September 2016 09:51:52 UTC-4, Kevin Conway wrote: > > Given a type T that implements interfaces A1 and A2, T is an acceptable > input for any function that requires an A1 or A2 as input. Given A1 and A2 > are identical in definition, the return value of a function that returns an > A1 is acceptable as input to a function at requires an A2, and vice versa. > > However, a type T2 defined as a function that accepts an A1 cannot be > satisfied by a function that accepts an A2. To illustrate, I've put > together a playground that encounters this issue: > https://play.golang.org/p/nsFCxP3T8H. > > To give a slightly more concrete example of why this is a pain point, > there is a common pattern among HTTP request routing libraries to define a > context sensitive alternative to the http.Handler interface defined as: > > type HanderC interface { > ServeHTTPC(context.Context, http.ResponseWriter, *http.Request) > } > > A benefit of the consistency across libraries is that my context sensitive > handlers are portable to virtually any routing library I want without > modification. However, each of these libraries also defines a form of > middleware which wrap a HandlerC. The typical pattern for these libraries > is to define a new type, Middleware, that is a function signature like > func(HandlerC) HandlerC. A problem with this approach is that middleware > become non-portable between libraries because a middleware defined as > func(A.HandlerC) A.HandlerC cannot be used to satisfy func(B.HandlerC) > B.HandlerC. > > This constraint feels odd because the interfaces required in the function > signatures are equivalent and, outside the context of that type definition, > are treated as equivalent in all ways. It is additionally frustrating > because the error message shown during compilation seems to indicate the > names of the types are being used for validation rather than the interfaces > themselves. > > Is this an expected behaviour with rationale behind the implementation or > is this considered a bug that will be resolved in future versions of go? > Alternatively, what strategies exist for overcoming this issue when > attempting to write code that is compatible with multiple, equivalent type > definitions? >
It's an expected consequence of the spec, so it's not a bug, but as you point out, it is certainly inconvenient at times and it is not a necessary restriction. There has been some recent discussion of relaxing the rules for assignability so that if interface types A1 and A2 are mutually assignable, then compounds made from them, such as []A1 and []A2, or func(A1) and func(A2), would be mutually assignable as well. See https://github.com/golang/go/issues/16209 -- 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.
