[swift-evolution] [Draft][Proposal] Formalized Ordering

[Matthew Johnson]

> On Jul 22, 2016, at 9:00 PM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Jul 22, 2016, at 4:55 PM, Daniel Duan via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>>> Well, it's still a very real question whether we ought to have the
>>> additional API surface implied by areSame, or wether we should collapse
>>> it with ===.
>>> 
>> 
>> To spell this out (because I had to think about it for a second): === will be derived from
>> <=>, but also becomes default implementation for ==, which remains open for customization.
>> 
>> I like this idea. If we keep === as a separate thing, now users have 3 “opportunities” to define
>> equality. The must be few, if any, use cases for this.
>> 
>> Would love to see if anyone on the list can give us an example. Otherwise we should make
>> areSame === again™!
> 
> If `===` is the new `areSame`, and `Hashable` is based on `===`, wouldn't that mean that objects could only be hashed (and thus, be looked up in Dictionary and Set) by identity? So, for instance, code like this:
> 
> 	var set = Set<NSString>()
> 	
> 	set.insert("test")
> 	set.insert("test")
> 	
> 	print(set.count)
> 
> Would print "2"? Or worse, might print "1" or "2" depending on the details of how Swift generates literals and Foundation implements short strings?
> 
> Am I the only one who thinks that's a problem?

This is super unfortunate.  The question is how hard we’re willing to push the need to implement types representing conceptual values as value types.  It seems like the right thing to do for the long run.  A “workaround” would be to use NSSet if you have to use Objective-C types that represent conceptual values.


> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution