> On Jul 11, 2016, at 7:28 PM, Mark Hamburg <[email protected]> wrote: > > On Jul 11, 2016, at 4:23 PM, Mark Hamburg <[email protected]> wrote: >> >> A bigger problem is that the requirement that something be equatable or the >> property that a type is not equatable becomes a hidden part of the interface. > > So, here is a more harsh suggestion: if a type can't be locally proven > equatable, then it is not equatable. > > This would break a lot of programs that use equality and inequality, but many > of those programs are arguably runtime errors waiting to happen.
Do you have examples of programs which would break and should not break? I had assumed the pessimistic rule would be applied, anyway, although I’m sure I’ve deleted previous posts which would have told me otherwise. :) If there are equatable types which could not be proven so, it would be better to give as an error message that “The type you are testing for equality with (==) cannot be proven to be equatable at this time. If you believe it really is equatable, try simplifying the involved code.” Christopher > > Mark > > -- > You received this message because you are subscribed to the Google Groups > "Elm Discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
