> > This would break a lot of programs that use equality and inequality, but > many of those programs are arguably runtime errors waiting to happen. >
This is true of literally any strongly-typed thing. The same was true when we decided to not allow incomplete pattern matches, but it was clearly worth it for Elm. Eliminating these runtime errors is, in my mind, cause enough to break existing code, since most code that breaks will be abusing = in some way. On Mon, Jul 11, 2016 at 4: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. > > 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.
