<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 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><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 style="margin:0 0 0 40px;border:none;padding:0px" class=""><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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><br class=""></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px" class=""><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><br class=""></div><div>Right; “_” is a placeholder for “don’t care”; it shouldn’t have different semantic meanings in different contexts.</div><br 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>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><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><div><br class=""></div><br class=""></body></html>