Dear Tony, > Am 19.07.2016 um 18:10 schrieb Tony Allevato <allev...@google.com>: >
> I floated a draft proposal a while back that addressed exactly this use case: > > https://gist.github.com/allevato/2fd10290bfa84accfbe977d8ac07daad I will take a look at it, thank you very much. > It's purely additive so it's effectively shelved till post-Swift-3, and there > are still some issues up for debate (the discussion thread was here > <http://thread.gmane.org/gmane.comp.lang.swift.evolution/18495>), but it > would likely address many of these concerns without going to the extreme of > forbidding explicit implementation of Equatable or the other suggestions > offered here (which I wouldn't support). I do not want to forbid it, but discourage it. It makes only sense in some occasions to override the default equality for value types, and the developer should be aware that he does something uncommon (like force unwrapping of optionals). But implementing equals and violating the contract should only be possible only, if you state that you really no what you are doing (like force unwrapping an optional that is via data-flow analysis *for sure* a `nil` or writing code in a code path that can for sure never bean reached (dead code)). Although, I think that there are only a few corner cases (like sink values) that could directly be modeled instead of allowing to do everything (like deciding whether to objects are equal depending on the dollar rate). But the other proposals like „default“ case and „dispatch“ for reference types are at least as important, if you look at my example where you can make two formerly equal objects unequal just by assigning them to another variable (with a different type)… All the best Johannes _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
