[swift-evolution] Custom equality/hash for Sets

[Jordan Rose]

Uh, it wasn't particularly thought through, but basically some way to tie the type of the Set to the implementations of == and hash. This could be something like C++ non-type template parameters, or a way to provide a custom conformance ("use this implementation of Hashable instead of the one that comes with the type") a la ML.*

I don't think either of these are near-term features, or possibly even far-term features. It was mostly just a way to say "this belongs in the type system for both correctness and performance reasons".

Jordan

* I don't actually grok <https://en.wiktionary.org/wiki/grok> ML modules yet.


> On Feb 18, 2016, at 20:23 , T.J. Usiyan <griotspeak at gmail.com <mailto:griotspeak at gmail.com>> wrote:
> 
> What do you mean by "put functions in generics"?
> 
> TJ
> 
> On Thu, Feb 18, 2016 at 11:04 PM, Jordan Rose via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> On Feb 18, 2016, at 16:09 , Dave Abrahams via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 
>> on Thu Feb 18 2016, Jacob Bandes-Storch <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> Would it make sense for the standard library Set to provide variants (or
>>> parallel versions of the same data structure) that take custom hashValue/==
>>> implementations at init time (functions taking in Elements), rather than
>>> relying on Hashable/Comparable protocols?
>>> 
>>> Use case: I want a set of objects that are compared for equality using ===
>>> rather than ==. This doesn't seem possible today, using Set, without
>>> creating some sort of wrapper object.
>>> 
>>> This particular case would be analogous to using NSHashTable with
>>> NSPointerFunctionsObjectPointerPersonality. (Maybe all I'm asking for is a
>>> Swiftier API for NSHashTable — including ArrayLiteralConvertible, using
>>> generics instead of UnsafePointer<Void>, etc.)
>>> 
>>> Similarly, C++'s unordered_map
>>> <http://en.cppreference.com/w/cpp/container/unordered_map <http://en.cppreference.com/w/cpp/container/unordered_map>> and friends have
>>> template parameters specifying the hash function and equality comparator,
>>> which use std::hash and == by default.
>> 
>> It might make sense.  How bad is the wrapper solution for user code?
> 
> struct CustomHashableFoo: Hashable {
>   var value: Foo
>   func hash() -> Int {
>     // custom hash function here
>   }
> }
> func ==(a: CustomHashableWrapped, b: CustomHashableWrapped) {
>   // custom == here
> }
> 
> Really not that bad, although you do have to get 'value' in and out of the box. It's also not reusable code—you have to rewrite the box for every type.
> 
> I'd say you usually don't want to allow custom hash/== closures because (a) then you have to store them somewhere, and (b) the compiler won't usually be able to inline them away. You also end up with a Set<Foo> that doesn't behave like a normal Set<Foo>—maybe you can insert equal-but-not-identical elements—which is bad if anyone's relying on normal Set-like guarantees.
> 
> -1 from me until we can put functions in generics, if ever.
> 
> Jordan
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160218/7cdab24f/attachment.html>