If we’re going to be bold about it, then let’s just solve this once and for all by removing all order dependent operations from
Collection conformance, use in
for-in loops, etc. I still don’t see why these are any less problematic than the other operations you’ve identified. This will leave only the ability to ask if they contain a given element, and remove all abilities to access all the contained elements as such access would inevitably reveal an order. These would then be truly unordered collections.
Unfortunately, that makes them essentially useless to anyone, because many algorithms are now either unimplementable or too computationally expensive to use. So instead I just accept that a Swift
Set is also a Swift
Sequence. This is inherent, and required to make them useful, not accidental, even if I can’t think of a great use for a few
Sequence methods. I also can’t think of a great use for calling
map on an infinite
Sequence, which is probably more harmful, and if I dig around the whole Swift protocol hierarchy I’m sure I can find a lot of similar examples that, nonetheless, probably don’t justify a more complex protocol hierarchy.
Now, the question remains about how exactly the fundamental
Sequence nature should be exposed here. As I said in the other thread, perhaps
Sequence conformance should have been provided as a view on
Set instead of conforming them directly, but it’s not clear to me that complexity would be worthwhile if we were starting from scratch, and I’m certainly not convinced it’s worth breaking source compatibility now. I also definitely don’t understand any solution here that retains a random assortment of functionality that reveals the ordering (e.g.
Collection functionality), while removing or quarantining another random assortment (e.g.
prefix). What would justify making that arbitrary distinction?