I don't think the String precedent is relevant here — and even if it is: Just because a concept was discarded for one specific case, that concept still can be valid for other situations.
I don't know the motivation for the original design (and was irritated when I had to use ".characters" as many others), but it's probably once again the question wether a string is made up of bytes or some more complicated unicode entity.
However, there is and was little doubt that a string is a collection (and a sequence), and that all of the order-dependent operations make sense for strings: You just could run into situations where you either have to deal with "incomplete" characters or buffer sizes which are to small because count handles some combinations of bytes as single elements.
So whereas for String, we just had to agree what type Element actually is, Set does not have such kind of ambiguity, and it is the type itself which causes contradiction.
Afaics, there is little resistance to remove the order-dependend methods from Set and Dictionary (nearly no one uses them -- and when they are used, it's probably an error), but it's not as clear if iteration should stay possible without indirection.
Is that true, or is there anyone who absolutely wants to keep Dictionary.starts(with:) and similar methods?
It depends how you think about it, I guess. e.g. some (many?) reasonable generic algorithms for Collection can be severely broken when used with certain Strings now, while the conformance of Set is semantically fine for such methods, though perhaps the results will not be useful.
When you say “remove” do you actually mean “move to a Collection conforming view property”, which is the proposal being discussed in this thread, or do you mean removed? I don't think any of these methods should be removed, but I would be happy to see all iteration and iteration-derived API moved to a view.
Not that. I explained it all here I think. Was it unclear?
Not at all, but you could have a problem with some hypothetical RangeReplaceableCollection algorithms. Nobody’s come up with a realistic example, though.
I might have been unclear -- with design, I was only referring to String.character. The quirks you mentioned are because of UTF, aren't they? (I can't see any serious problems with concatenation of an array of bytes... except maybe a C style string, where the null that signals its end is part of the collection).
I guess I was unclear. The quirks are not because of encodings (what I presume you mean by UTF), but because of the way some characters combine when you put them next to one another.
Looks like we actually meant the same phenomenon: afaik, for ASCII and many other "old" encoding schemes, the number of characters always matches the number of bytes (but I wouldn't be surprised if there are exceptions -- problems with encodings have a long tradition ;-)
I have also been wondering about this approach. This protocol could also support indices that can be discovered using index(where:) and index(of:) as well as sorted and maybe even reduce where combine is commutative. If Swift gets support for HKT in the future it could also support map, compactMap and filter.
I don't think this should be called UnorderedCollection though as I think Collection (or MaterializableCollection) should refine it if it gets added. If we were starting from scratch I might consider calling this Collection but I don't think that's a viable today. The name Container was mentioned in one of the recent threads related to this topic. That's the best available option I've been able to think of.