SE-0241 also proposed within: labels originally, and updated to in: labels during the review (in commit 14a1643).
3 Likes
I prefer to have a method to normalize / canonicalize the RangeSet if it is not supposed to be by default.
+1 on the proposal. If we're bikeshedding names, SegmentSet might get us away from the semi overload of Range along with encloses(_) or encompasses
In mathematics and computing, most sets are not a finite, explicit constructive collection of elements — but rather a possibly-infinite, implicit non-constructive set defined through a predicate that decides wether or not an element is a member of the set.
In Swift the type Set must be created by enumerating all its elements. You add elements to the set, and the set is defined in terms of its members. If an arbitrary other value is equal to a member, it is considered to be contained in the set.
However, in some programming languages there are PredicateSet which does not have a finite, well-defined list of elements. Instead, they have a rule that defines wether a given value is included or not. Adding to the set, means OR-ing two a predicate to the existing. Removing from the set, means AND NOT-ing to the existing predicate. A predicate set is not a set-of-predicates, but a set-defined-by-a-predicate. In fact, there once was a pitch to add PredicateSet to Swift, if I recall correctly.
RangeSet fits perfectly, IMHO. I don't have problem with the name at all. It's not merely a set-of-ranges, but a set-defined-by-ranges. When you add to the set, you extend its definition.
(Similarly, Foundation already has CharacterSet. It is kinda like a predicate set, but kinda also like an element set. I don't know how it is implemented. It allows you to add specific characters, but you can't enumerate its members. I suspect it uses ranges under the hood.)
7 Likes
What you say is correct, but I think you're conflating two separate issues.
The problem with RangeSet is not that it's an inappropriate name for the proposed type, but that it's too general. Swift keeps shooting itself in the foot by using up general names for specific things. If you want a good example of this, go upthread to the comments about SetAlgebra. This gist of these is that it's not really the thing that we want to call SetAlgebra, but it uses up the more general name, yet it's too late to rename it.
The second issue is whether the semantics of "operations on noncontiguous elements" should be formally specified in terms of an underlying implementation that uses ranges. In that case, it's not an issue of what the thing is called, but the semantics of its behavior.
I would be happy with the naming if we compromised with, say, IndexRangeSet, but I'm not yet convinced that the type itself is the right design abstraction for the proposed APIs. (Clearly I'm in the minority here, but that's OK.)