Some Python examples:
if 2 < 3 < 4 == 4 <= 5 { … }
a = b = c = 1
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:
x op1 y op2 z
Turn into:
(x op1 y) && (y op2 z)
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.
-Sune
···
On 17 Dec 2015, at 19:44, Amir Michail via swift-evolution <swift-evolution@swift.org> wrote:
Some Python examples:
if 2 < 3 < 4 == 4 <= 5 { … }
a = b = c = 1
Joe, Rob Rix, Scott Perry, and I actually tossed around some ideas about chained operators on Twitter <https://twitter.com/jckarter/status/666321957458079744> last month. My initial idea was just to make operators variadic:
func
(values: Int...) -> Int
a
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:
operator •, ¶ { associativity chained(§) }
a • b ¶ c ==> (a • b) § (b ¶ c)
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:
a <= b < c
b ~= a..<c
…as long as your lower bound uses <=.
(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.)
As for multiple assignments, we mainly didn't want people doing other 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"?
It's feasible, but it's not very common in practice, and it would mess up our AST a bit.
Jordan
···
On Dec 17, 2015, at 10:49 , Sune Foldager via swift-evolution <swift-evolution@swift.org> wrote:
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:
x op1 y op2 z
Turn into:
(x op1 y) && (y op2 z)
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.
-Sune
On 17 Dec 2015, at 19:44, Amir Michail via swift-evolution <swift-evolution@swift.org> wrote:
Some Python examples:
if 2 < 3 < 4 == 4 <= 5 { … }
a = b = c = 1
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
So no man is an
island, but snowman is an
operator - hah!
-Kenny
···
On Dec 17, 2015, at 8:30 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:
Joe, Rob Rix, Scott Perry, and I actually tossed around some ideas about chained operators on Twitter last month. My initial idea was just to make operators variadic:
func
aBut 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:
operator •, ¶ { associativity chained(§) }
a • b ¶ c ==> (a • b) § (b ¶ c)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:
a <= b < c
b ~= a..<c…as long as your lower bound uses <=.
(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.)
As for multiple assignments, we mainly didn't want people doing other 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"?
It's feasible, but it's not very common in practice, and it would mess up our AST a bit.
Jordan
On Dec 17, 2015, at 10:49 , Sune Foldager via swift-evolution <swift-evolution@swift.org> wrote:
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:
x op1 y op2 z
Turn into:
(x op1 y) && (y op2 z)
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.
-Sune
On 17 Dec 2015, at 19:44, Amir Michail via swift-evolution <swift-evolution@swift.org> wrote:
Some Python examples:
if 2 < 3 < 4 == 4 <= 5 { … }
a = b = c = 1
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution