[swift-evolution] Universal Equatability, Hashability, and Comparability
marksands07 at gmail.com
Tue May 24 10:46:25 CDT 2016
I apologize upfront for necromancing this thread. Is there any momentum on
My team was discussing the merits of default (opt-in) Equality. As soon as
the equality function has been written then the compiler is satisfied, but
there is no way to get compile time correctness for the equality. Unit
tests can only go so far with ensuring the equality function is robust.
Once a new property is added to a struct, for instance, the equality
function is no longer correct and without warning. Currently there is no
way to safeguard this situation. This would be a welcome addition to Swift.
On Fri, Mar 11, 2016 at 11:19 AM, Jose Cheyo Jimenez via swift-evolution <
swift-evolution at swift.org> wrote:
> > (starting a new thread by DaveA's request)
> > There's a definition of equality that makes sense as a default for
> nearly every type in our system:
> > - Basic types like IntNN, FloatNN, String, etc. have domain-defined
> > - Structs and tuples can be considered equal if their corresponding
> fields are equal,
> > - Enums can be considered equal if they carry the same, equal payload,
> +1 for Equality, Comparable and Hashable especially for enums and tuples.
> I know that equality was added for tuples but I think that enums are
> perfect for adding automatic generation of conformance to Equality,
> Comparable and Hashable.
> Take a look at this toy example of an Enum with 9 cases
> boiler plate to conform to Equatable
> boiler plate to conform to Comparable
> > It's my feeling that Equatable and Hashable would make a lot of sense as
> universal operations; I'm not so sure about Comparable.
> > -Joe
> For enums a defaultComparable protocol could just rank on the order the
> fields are declared:
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution