<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:20, 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" 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=""><br class="Apple-interchange-newline">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="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; 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 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: 0px 0px 0px 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 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=""><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="">Why would it make sense to have `_` as an alias for Void?</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=""> </div><blockquote class="gmail_quote" 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; 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 style="word-wrap: break-word;" class=""><div class=""><br class=""></div><blockquote style="margin: 0px 0px 0px 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 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=""><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="">I disagree that this proposed use of the underscore is consistent with other uses.</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=""><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="">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></blockquote><div><br class=""></div><div>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.</div><div><br class=""></div><div>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.</div><div><br class=""></div><blockquote type="cite" 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="">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></blockquote><br class=""></div><div>Well then hopefully one of them will see fit to discuss why that is so? 😝</div></body></html>