[swift-evolution] Custom equality/hash for Sets

[T.J. Usiyan]

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> wrote:

>
> On Feb 18, 2016, at 16:09 , Dave Abrahams via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> on Thu Feb 18 2016, Jacob Bandes-Storch <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> 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
> 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/075904b0/attachment.html>