Objective-C wanted to work with C, so it had both Smalltalk keyword function calls between square brackets and un-labeled C-style functions using parentheses.
C wants to fit in the C family with a unified function call syntax, and as time goes on, this is what you get.
And since keywords naturally go between their arguments, there is no need for “operators”, as a very different and special syntax form. You just allow some “binary” keywords to look a little different, so instead of 2 multiply:3 you can write 2 * 3.
How does this approach support operator precedence?
It doesn’t. Or at least Smalltalk doesn’t, and neither does my baby, Objective-Smalltalk.
There is some form of precedence: unary binds stronger than binary binds stronger than keyword.
Other than that, evaluation is strictly left-to-right, which apparently was the option that caused the least confusion overall, even if it discarded old conventions.
As usual, the curse of C strikes back.
Objective-C wanted to work with C, so it had both Smalltalk keyword function calls between square brackets and un-labeled C-style functions using parentheses.
C wants to fit in the C family with a unified function call syntax, and as time goes on, this is what you get.
I always liked the visual distinction between Smalltalk style and C style in Objective-C.
I meant to write: Swift wants to fit in the C family with a unified function call syntax, and as time goes on, this is what you get.
How does this approach support operator precedence?
It doesn’t. Or at least Smalltalk doesn’t, and neither does my baby, Objective-Smalltalk.
There is some form of precedence: unary binds stronger than binary binds stronger than keyword.
Other than that, evaluation is strictly left-to-right, which apparently was the option that caused the least confusion overall, even if it discarded old conventions.
Operator precedence is a dangerous set of conventions to learn, or just bypass with a lot of parentheses. It is not a feature, but a side effect.