Thanks for the replies everyone, I've now had a few nights to sleep on this. Considering what @AlexanderM said and having spoken to @zachrwolfe about the implementation, it does make sense to make
Hashable a requirement. I was looking for other possibilities, but in this case its just the nature of the beast.
I've updated the draft proposal to reflect those changes and added an implementation that seems to run pretty well.
I did play with the idea of
unique() myself, but it kind of felt like saying the array itself was unique not the elements within it. Thats why I took the naming idea from other languages and stuck with
distinct. I'm open to changing it to that if others think the same, but thats the reason why I settled on the naming that I did.
This is also something I've been fighting with as you are right, it does make sense to be chained up like that. I think this capability makes sense, but the naming doesn't fit. On the other hand it also doesn't fit with
uniqued() either, so maybe there is another terminology we can use here?
I do like the idea of having the ability available to
String too. Maybe this is better to be an addition to the
RangeReplaceableCollection without the restriction of
MutableCollection too. I'm open to opinions on this and will happily update it if there aren't any objections.