<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr">On Tue, Apr 25, 2017 at 8:55 AM Haravikk via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></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"><div>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><br></div><div>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><br></div><div>With a Void "open" argument this would look like:</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><font face="Monaco">func ... <T:Comparable>(lhs:T, rhs:Void) -> RangeFrom { ... }</font></div><div><font face="Monaco">func ... <T:Comparable>(lhs:Void, rhs:T) -> RangeTo { ... }</font></div><div><font face="Monaco"><br></font></div><div><font face="Monaco">let rangeFrom = 5 ... ()</font></div><div><font face="Monaco">let rangeTo = () ... 5</font></div></blockquote><div><br></div><div>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><br></div><div>Why would it make sense to have `_` as an alias for Void?</div><div> </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"><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div><font face="Monaco">let rangeFrom = 5 ... _</font></div></div><div><div><font face="Monaco">let rangeTo = _ ... 5</font></div></div></blockquote><div><br></div><div>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><br></div><div>I disagree that this proposed use of the underscore is consistent with other uses.</div><div><br></div><div>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><br></div><div>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><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div></div>