In the FAQ entry for *Why doesn't type T satisfy the Equal interface?*, an assertion is made that full-on subtypes are required in order to determine if the interface can be satisfied.
While a subtypes capability would be sufficient, is it essential? The requirement for subtypes would appear to address the larger issue of polymorphism of interfaces and *structs*. Where the receiving parameter is an interface, as per the FAQ, is it not sufficient for the compiler to just check whether the parameter type T implements the receiver parameter interface? Fail if the receiver parameter is not an interface type or if the interface is not implemented. Otherwise allow. For context, and as a concrete example, I have three (and counting) complex structs that I need to map as keys to other complex structs. I could 1) implement code duplicates, differing in types and type naming, 2) fudge in some instance identifier into each struct and add corresponding complexity throughout the codebase, or 3) implement the algorithm as an interface <https://play.golang.org/p/wOfl-bSrwZ> and utilize from the awesome capabilities of go to simplify design issues. So I chose (3) and promptly ran into the problem addressed by the FAQ. It is the only problem with this approach. Would adding the compiler check for interface implementation be sufficiently simple to be worth the effort? Even only as an interim step towards full subtyping? Seems like this approach to type specialization would be very useful -- it could be considered a form of generics, from a certain point of view. Finally, before I spend the time to implement (2) in my own code, are there any other approaches that I should consider? Thanks, Gerald -- 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.
