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

[Douglas Gregor]

> On Apr 25, 2017, at 9:20 AM, Tony Allevato <tony.allevato at gmail.com> wrote:
> 
> 
> On Tue, Apr 25, 2017 at 8:55 AM Haravikk via swift-evolution <swift-evolution at swift.org <mailto: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.

Right; “_” is a placeholder for “don’t care”; it shouldn’t have different semantic meanings in different contexts.

> 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.

Yes, the core team did consider the ideas around using the binary operators rather than introducing the new prefix/postfix operators, and felt that the proposal provided the clearest Swift code.

	- Doug


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170425/bc6907f4/attachment.html>