FloatingPoint should imply Hashable.

[stephentyrone]

This is a bug fix adding conformance to Hashable to the FloatingPoint protocol. The concrete types already conform.

Resolves SR-4132.

[stephentyrone]

@swift-ci Please smoke test.

[jrose-apple]

I'm not sure why FloatingPoint would imply Hashable. The two concepts (in the technical sense) have nothing to do with each other.

[dabrahams]

on Thu Mar 02 2017, Jordan Rose <notifications-AT-i.8713187.xyz> wrote:

I'm not sure *why* FloatingPoint would imply Hashable. The two concepts (in the technical sense) have nothing to do with each other.

If you can implement hashability in terms of existing FloatingPoint primitives, they do. Can you, @stephentyrone?

…

-- -Dave

[jrose-apple]

That's still not true. You can implement Collection on any BinaryInteger type to give you a collection of Bools, but it doesn't mean they're related concepts.

[stephentyrone]

@jrose-apple That's a fair point, and with conditional conformance we probably don't need this. Without conditional conformance, it's something of a minor pain, forcing you to define your own FloatingPoint + Hashable protocol. =)

[dabrahams]

@jrose-apple @stephentyrone Hashable conformance confers a core capability that every type should provide if it can, just like Equatable and Comparable. There's almost no excuse for any Equatable thing not to also be Hashable; the exception is when the underlying representation may be denormalized in some way that makes them impossible or expensive to normalize (e.g. Set). Floating point numbers have denormalized forms, so for me this comes down to the cost of normalization. If @stephentyrone can't imagine a representation whose normalization is much more expensive than the subsequent hashing step, I think the conformance belongs.

[jrose-apple]

That's new information that I'm not sure is well-established. I'd say Hashable is even more "core" than Comparable, but that still doesn't mean it has anything to do with FloatingPoint. It's not like it's hard or less correct to make it an additional constraint on your generic functions.

(I'm not even against providing a default implementation. It just bothers me to see unrelated protocols connected together because it's convenient.)

[dabrahams]

I don't buy the premise that they're unrelated. Hashable is related to Equatable, and FloatingPoint is Equatable, presumably with enough additional constraints that Hashable conformance is practical. Concept clustering is a thing, and separating concepts should require evidence.

BTW, Hashable is exactly as core as Comparable. In fact I think it can be implemented in all the same cases. Maybe they should be folded together.

[stephentyrone]

Hashable is related to Equatable, and FloatingPoint is Equatable, presumably with enough additional constraints that Hashable conformance is practical.

If this is the standard, then yes it should conform to Hashable, and it is a bug for it not to.