<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=""><div class="">Joe, Rob Rix, Scott Perry, and I actually tossed around some ideas about chained operators <a href="https://twitter.com/jckarter/status/666321957458079744" class="">on Twitter</a> last month. My initial idea was just to make operators variadic:</div><div class=""><br class=""></div><div class=""></div><blockquote type="cite" class=""><div class="">func ☃(values: Int...) -> Int<div class="">a ☃ b ☃ c ☃ d</div></div></blockquote><div class=""><br class=""></div><div class="">But that doesn't allow mixing < and <=. I'm fine with disallowing mixing in general, but those two you usually want to choose from. Joe's idea is a little more extensible:</div><div class=""><br class=""></div><div class=""><div class=""></div><blockquote type="cite" class=""><div class="">operator •, ¶ { associativity chained(§) }</div><div class="">a • b ¶ c ==> (a • b) § (b ¶ c)</div></blockquote><br class=""></div><div class="">But it's still a little weird. (Are there any useful chains other than "&&"?) Thus the canonical way to compare ranges remains the match operator:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">a <= b < c</div><div class="">b ~= a..<c</div></blockquote><div class=""><br class=""></div><div class="">…as long as your lower bound uses <=.</div><div class=""><br class=""></div><div class="">(P.S. You can totally fake this by overloading < and <= with a mess of operators and intermediate types, but it's pretty nasty, and I wouldn't inflict the errors you get out on an average developer.)</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">As for multiple assignments, we mainly didn't want people doing <i class="">other</i> things with the result of an assignment expression (e.g. "foo(x = bar())"). Chained assignment has interesting semantics for computed properties, though: for "a.foo = b.bar = c", does "a.foo" get assigned the value of "c" or "b.bar"?</div><div class=""><br class=""></div><div class="">It's feasible, but it's not very common in practice, and it would mess up our AST a bit.</div><div class=""><br class=""></div><div class="">Jordan</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 17, 2015, at 10:49 , Sune Foldager via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hmm, I don’t think it’s worth the added complexity that it will surely result in. Also, for non-standard operators it’s hard to see how it would be evaluated. Would:<br class=""><br class="">x op1 y op2 z<br class=""><br class="">Turn into:<br class=""><br class="">(x op1 y) && (y op2 z)<br class=""><br class="">for boolean-returning operators? I guess that could make sense, but I’m not sure I like the syntax much. I think it looks ok for x < y < z, but otherwise it gets confusing.<br class=""><br class="">-Sune<br class=""><br class=""><blockquote type="cite" class="">On 17 Dec 2015, at 19:44, Amir Michail via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">Some Python examples:<br class=""><br class="">if 2 < 3 < 4 == 4 <= 5 { … }<br class=""><br class="">a = b = c = 1<br class=""></blockquote><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></body></html>