> * What is your evaluation of the proposal?
I like this proposal, except for the `precedencegroup` syntax, which I think is
a bit overwrought. Rather than this proposal's:
precedencegroup Multiplicative {
associativity(left)
precedence(> Additive)
}
I would prefer to see:
precedence Multiplicative > Additive left
(Or possibly, if the `left` is deemed too inexplicable by itself,
`associativity(left)`.) I don't really think the `precedence` keyword or the
curly brackets bring much to the declaration, and dropping them allows us to
replace the awkward compound `precedencegroup` with the shorter and equally
explanatory `precedence`.
> * Is the problem being addressed significant enough to warrant a change
> to Swift?
Yes. The numeric precedence levels are a significant wart, an impedance to both
reading the standard library and implementing new custom operators.
> * Does this proposal fit well with the feel and direction of Swift?
Yes. Magic numbers are un-Swifty.
> * If you have used other languages or libraries with a similar feature,
> how do you feel that this proposal compares to those?
The only language I know which has equivalently powerful custom operator
specification is Perl 6. When you define a new operator in Perl 6, you're asked
to declare it `is tighter`, `is looser`, or `is equiv` to another operator.
`tighter` and `looser` both introduce a new precedence level between the
operator you specified and the next closest existing precedence level.
The Swift solution seems better because it asks you to design your precedence
hierarchy first and then assign operators to its levels. It also allows for two
operators to have no precedence relative to each other, so they have to be
parenthesized.
However, one good thing about the Perl 6 solution is that it lets you introduce
new precedence levels between the existing ones. It's not clear to me if this
proposal allows that, and if so, how. (I don't believe any of the examples
demonstrate that.)
> * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
Quick reading.
--
Brent Royal-Gordon
Architechies
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
