(This may be a more appropriate topic for Evolution, but here we go…)
The text of SE-0172 never described a facility for unbounded ranges, but nevertheless the implementation ended up growing one. At the moment, it’s definitely creaky; it only works with the one subscript on
Collection, not on anything that takes
<T: RangeExpression>. This is not only annoying when composing the use of stdlib APIs, but also painful for writing your own APIs that use
RangeExpression; this is especially true if it’s a revision of a previous API that took fully-bounded
RangeS, because there you could always say
Range<X>? = nil.
As an individual contributor, I find myself reaching for
... fairly often to mean an unbounded range and being frustrated when it doesn’t work. As a member of a team, the syntax might as well not be there because I can’t adequately explain to others what special cases it does and does not work in without them already being fully versed in the design of the standard library.
The current approach in the standard library is non-ideal and it would be non-ideal to keep it in place for the standard library’s ABI to get locked in.
Long story short, what can we do?
- Can we lift the limitations the prevent a free-standing
...from working as a calling-the-operator expression? (i.e.,
func ...() -> UnboundedRange)
- Can we lift the limitations that prevent a free-standing
...from working as a named lookup? (i.e.,
public let ...: UnboundedRange)
- Can we replace the
_UnboundedRangehack with some other kind of sigil (not the Unicode ellipsis, please) that is phased out if of the above can happen?