[swift-evolution] [Accepted] SE-0172: One-sided Ranges

[Tony Allevato]

On Tue, Apr 25, 2017 at 8:55 AM Haravikk via swift-evolution <
swift-evolution at swift.org> wrote:

> While it's good that this was accepted I still feel there could be some
> more discussion about whether the operators should be prefix/postfix or
> instead involve a more explicit declaration of one-sidedness.
>
> I still would very much prefer that the operator declarations were binary
> and take Void as a second argument, this way there is very explicit
> indication that one-sidedness was requested, rather than potentially
> accidental; assuming many subscripts and methods that take currently closed
> ranges will be updated to also take one-sided ranges, the distinction is
> very important as a omitting one of the values could represent a mistake,
> and result in one-sided behaviour with unintended consequences.
>
> With a Void "open" argument this would look like:
>
> func ... <T:Comparable>(lhs:T, rhs:Void) -> RangeFrom { ... }
> func ... <T:Comparable>(lhs:Void, rhs:T) -> RangeTo { ... }
>
> let rangeFrom = 5 ... ()
> let rangeTo = () ... 5
>
>
> Not the prettiest with the Void brackets, however, if we could in future
> get underscore as another alias for Void we could refine this into:
>

Why would it make sense to have `_` as an alias for Void?


>
> let rangeFrom = 5 ... _
> let rangeTo = _ ... 5
>
>
> This would have consistency with other uses of underscore that are used to
> indicate that something is being ignored on purpose, which I think fits
> this proposal very well. It would also leave the prefix/postfix ellipsis
> operator free for use on something else with less chance of creating
> ambiguity.
>

I disagree that this proposed use of the underscore is consistent with
other uses.

The underscore is used as a pattern matching construct that means "I don't
care what actual value goes here; match and allow anything and throw it
away." But in the range case, not only is this not a pattern, but you also
*do* care very much what value is used there—not any arbitrary value is
acceptable. The value you want is the least or greatest possible value for
that range.

Regardless, these ideas were brought up during the proposal's discussion
and it's probably safe to assume that the core team considered them but
felt they weren't a good solution.



> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170425/a8a4955e/attachment.html>