[swift-evolution] Custom equality/hash for Sets

[T.J. Usiyan]

Thank you for the clarification!

On Thu, Feb 18, 2016 at 11:33 PM, Jordan Rose <jordan_rose at apple.com> wrote:

> 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> 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> 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/20160219/78b4ae41/attachment.html>