<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 25 Apr 2017, at 17:47, Douglas Gregor <<a href="mailto:dgregor@apple.com" class="">dgregor@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">On Apr 25, 2017, at 9:20 AM, Tony Allevato <<a href="mailto:tony.allevato@gmail.com" class="">tony.allevato@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, Apr 25, 2017 at 8:55 AM Haravikk via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div class="" style="word-wrap: break-word;"><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">With a Void "open" argument this would look like:</div><div class=""><br class=""></div><blockquote class="" style="margin: 0px 0px 0px 40px; border: none; padding: 0px;"><div class=""><font face="Monaco" class="">func ... <T:Comparable>(lhs:T, rhs:Void) -> RangeFrom { ... }</font></div><div class=""><font face="Monaco" class="">func ... <T:Comparable>(lhs:Void, rhs:T) -> RangeTo { ... }</font></div><div class=""><font face="Monaco" class=""><br class=""></font></div><div class=""><font face="Monaco" class="">let rangeFrom = 5 ... ()</font></div><div class=""><font face="Monaco" class="">let rangeTo = () ... 5</font></div></blockquote><div class=""><br class=""></div><div class="">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:</div></div></blockquote><div class=""><br class=""></div><div class="">Why would it make sense to have `_` as an alias for Void?</div><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div class="" style="word-wrap: break-word;"><div class=""><br class=""></div><blockquote class="" style="margin: 0px 0px 0px 40px; border: none; padding: 0px;"><div class=""><div class=""><font face="Monaco" class="">let rangeFrom = 5 ... _</font></div></div><div class=""><div class=""><font face="Monaco" class="">let rangeTo = _ ... 5</font></div></div></blockquote><div class=""><br class=""></div><div class="">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.</div></div></blockquote><div class=""><br class=""></div><div class="">I disagree that this proposed use of the underscore is consistent with other uses.</div><div class=""><br class=""></div><div class="">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.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Right; “_” is a placeholder for “don’t care”; it shouldn’t have different semantic meanings in different contexts.</div></div></div></blockquote><div><br class=""></div><div>"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.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class="">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.</div></div></div></div></blockquote><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">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.</div></div></blockquote></div><br class=""><div class="">Can you please qualify this further? How is this clearly a one-sided range rather than a mistake:</div><div class=""><br class=""></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>let values = someArray[5...] // This one I wanted to be a one-sided range</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>let values = someArray[5...] // Scrolled up for correct endpoint to use, but forgot to fill it in</font></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div></body></html>