On Sun, Sep 9, 2018 at 8:49 PM Jonathan Amsterdam <jbamster...@gmail.com> wrote:
> The problem is that this program seems to type-check, but it is invalid. > The == operator is specified to work on operands of the same type, and it > is being used on operands of different types. > Good point. I have to think about it. An ad-hoc solution, FWIW, would be to only take into account (or allow) pseudo-interfaces for type-constraints. But I agree, of course, that this isn't necessarily a nice way to think about it. And since we need some operators for generics (at least == and <), it is > also one of the fundamental problems with unifying interfaces and contracts. > I disagree with the premise that we *need* operators for generics - when I think of "generics", I usually think of "type-safe, constrained, parametric polymorphism". Without operators, generic code would still fulfill that definition. I agree that being able to use operators would make generics far more convenient and require less boilerplate. And I agree that that means we probably want to have them for generic code. But saying they are fundamentally needed IMO over constrains the design space. > -- > 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. > -- 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.
