> On Nov 9, 2017, at 4:29 AM, Xiaodi Wu <[email protected]> wrote:
>
> Why not? Specifically, why shouldn't we require `Hashable` conformance on
> indices? Adding it would require changes to conforming types, sure, but
> indices are already required to be `Equatable`, and `Hashable` conformance
> just got really easy to add, and custom `Collection`s are a relatively rare
> and advanced feature.
>
> For a source-breaking change, that’s the wrong question to ask. It’s not “why
> not,” but “why so”? It’s so easy to add the conformance, and any type can opt
> into it so easily, what is the gain by forcing it and can it be justified as
> a source-breaking change?
You're right that source-breaking changes need to be justified. What I would
say is:
1. This proposal as written will require many conditional conformances;
it would be better (and would allow us to fully implement it sooner) if they
were unconditional.
2. Relying on `where` clauses does not help you in type-erased code.
`AnyIndex` cannot conditionally conform to `Hashable` because it erases types,
and it's not clear to me whether `AnyIndex` can be cleanly converted to
`AnyHashable` or vice versa. This means code using type erasure may be awkward
to write if it needs `Hashable` indices.
3. The `KeyPath` case discussed in this proposal is another example
where ad-hoc `Hashable` indices cause trouble for type erasure (in that
`KeyPath`s erase the types of the indices inside them). It would be very weird
for `KeyPath`s to only support indices if they happen to also be `Hashable`.
4. `Hashable` conformance is extremely useful in general. It allows,
among other features, use as a `Set` or `Dictionary` key, and apparently now
use in `KeyPath` as well. Replacing an `Array` of indices with a `Set`, or
switching from some other representation to a `KeyPath`, is the sort of change
we would like generic algorithms to be able to make without breaking binary
compatibility with their callers.
5. `Hashable` occupies a special place of importance among our standard
protocols. In the past, we've occasionally discussed making it mandatory and
impossible to opt out of; many languages actually do that. Even though we
haven't, I've seen experts make flat statements along the lines of "All value
types should conform to `Hashable`". This is not like requiring an index to be,
say, `Strideable` or a `SignedInteger`.
6. The compiler can now automatically synthesize `Hashable` conformance
for many simple types; this makes the burden of requiring a conformance
unusually low.
7. I have written several custom collections, and it has never occurred
to me to conform the index to `Hashable`, but now that it's been mentioned I
realize that it would have been both easy and extremely useful to do so. My
index types would already have been `Hashable` if the standard library had
forced me to do so.
Basically, what it comes down to is, `Hashable` is very useful and there are
not many plausible index designs which would have trouble supporting it. It is
not absolutely necessary to make this change, but I think it would lead to
better, more useful types with a fairly low burden.
--
Brent Royal-Gordon
Architechies
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
