> Am 15.07.2016 um 18:12 schrieb Johannes Neubauer via swift-evolution > <[email protected]>: > > >> Am 15.07.2016 um 15:19 schrieb Shawn Erickson <[email protected]>: >> >> Additional two "things" maybe considered equal in the chosen problem domain >> despite their identity (memory location, etc.) being different. Having the >> ability to supply custom hash and equality for types can be a useful tool in >> a developers toolbox. For example two pathways of code may create what is >> actually the same thing (say a reference to the same file on disk) then want >> to work with stdlib set and/or dictionary with the equivalent things being >> resolved correctly, etc. >> >> To remove custom equality will limit some designs and to force identity >> based equality with present similar problems on the other end of the >> spectrum. > > It is only for value types. For reference types, which have an identity, you > are right, but it doesn’t hold for values.
Sorry, this can be misunderstood. I meant: I would remove custom equality only for value types (for the reasons I meant above). The fixed implementation of checking equality for value types would check equality `==` of all referenced structs and reference types implementing `Equatable`. If a reference type does not implement `Equatable` `===` will be used. If the shiny days will come, where indirect storage is used for value types with at least two properties with reference types (or other value types with indirect storage) **automatically**, with the guarantee that these storages are uniquely stored in a given value table/pool, then `===` can be used for that too (e.g. for the storage of Arrays or Strings, which would then be automatically generated either!).
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
