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

[Haravikk via swift-evolution]

> On 25 Apr 2017, at 17:47, Douglas Gregor  wrote:
> 
>> 
>> On Apr 25, 2017, at 9:20 AM, Tony Allevato > > wrote:
>> 
>> 
>> On Tue, Apr 25, 2017 at 8:55 AM Haravikk via swift-evolution 
>> > 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 ... (lhs:T, rhs:Void) -> RangeFrom { ... }
>> func ... (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.

"Don't care" is little different to "omit", which is what is would be happening 
in the case of declaring a one-sided range. It's not a radically different 
meaning in different contexts, it's just slightly widening what it means.

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

Can you please qualify this further? How is this clearly a one-sided range 
rather than a mistake:

let values = someArray[5...] // This one I wanted to be a one-sided 
range
let values = someArray[5...] // Scrolled up for correct endpoint to 
use, but forgot to fill it in

I just don't think that we should throw away the property whereby a range is 
incomplete until a second value or something else is given. If not an 
underscore then something else would be fine, even just the brackets that we 
have now to represent Void; omitting arguments is fine in methods and functions 
where it's still clear, but I just don't think that this is the case here, as 
this isn't a unique new operator, it's an overload of an existing one that does 
essentially the same thing but differently.

The only similar case that springs to mind is that we an exclamation both for 
negation, and force-unwrapping, but they're used at different ends to an 
argument, so it's not similar in practice.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Douglas Gregor via swift-evolution]

> On Apr 25, 2017, at 9:20 AM, Tony Allevato  wrote:
> 
> 
> On Tue, Apr 25, 2017 at 8:55 AM Haravikk via swift-evolution 
> > 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 ... (lhs:T, rhs:Void) -> RangeFrom { ... }
> func ... (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


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Haravikk via swift-evolution]

> On 25 Apr 2017, at 17:20, Tony Allevato  wrote:
> 
> 
> On Tue, Apr 25, 2017 at 8:55 AM Haravikk via swift-evolution 
> > 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 ... (lhs:T, rhs:Void) -> RangeFrom { ... }
> func ... (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.

To me the concept of not caring what a value is, and not wanting to specify one 
are consistent; in both cases they are effectively wildcards. The difference is 
that in one context (pattern matching) it's "match anything but don't bother 
assigning it" while in the other (one-sided range) it's leaving the actual or 
effective value up to the implementation of the subscript/method, which is what 
in reality you are doing anyway.

Either way you're ignoring part of the argument, and IMO it's better that this 
is done more explicitly to avoid ambiguity and/or mistakes. Maybe underscore is 
the best option, but if not, I'd like to discuss that as well. Even if it meant 
leaving me with using brackets, I'd still prefer that to omitting one side of 
the range as it would mean giving an explicit declaration of intent.

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

Well then hopefully one of them will see fit to discuss why that is so? ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Tony Allevato via swift-evolution]

On Tue, Apr 25, 2017 at 8:55 AM Haravikk via swift-evolution <
swift-evolution@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 ... (lhs:T, rhs:Void) -> RangeFrom { ... }
> func ... (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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Haravikk via swift-evolution]

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 ... (lhs:T, rhs:Void) -> RangeFrom { ... }
func ... (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:

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.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Douglas Gregor via swift-evolution]

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0172-one-sided-ranges.md

Hello Swift Community,

The review of SE-0172 “One-sided Ranges” ran from April 17...23, 2017. The 
proposal is accepted for Swift 4. Thanks to everyone who participated in the 
discussion!

- Doug
Review Manager

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution