you specify Hashable only when needed (e.g. to put it into a PureDictionary / PureSet which is hash based)
just that the inability to customise them would prohibit spooky action at a distance for other pure value collection types (dict/set) they reside in (if they are). thus keeping them pure.
La loi, c'est la loi. Comparable (if value wants to conform to it) would be provided by the compiler itself with no ability of customisation (yes, i am talking about memcmp (and nested memcmp's of nested types). there are somewhat tangentially related precedent and precedent. no, PureTreeDictionary / PureSortedSet will not be sorted according to the current language / locale rules (neither is SortedSet, nor is "Å < Æ")
alternatively...
we could explore a different direction altogether, with some concept of "very pure function that can't depend on anything but the value itself" and whereas it would be a compilation error to try:
var storage: [String] = ...
struct PureStruct: PureValueType, HashableValue {
verypure func == (right: Self) -> Bool {
storage[left.v] == storage[right.v] // compilation Error:
// verypure methods can't reference external data
}
}
i like this less, it's quote far from swift, as it is now.
i don't know about this one, but i believe that would be similar to the situation with EQ/hash/LessThan. perhaps in addition (if needed) you'd point compiler to particular fields (mark them as such) that establish value identity and compiler does everything else.