[Review] SE-0077: Improved operator declarations

Jeremy, inline:

By the way, in the future directions version of the BitwiseShift group we

     members(<<, >>)
Is that a typo?

Thanks, will try to fix it.

Also, just to confirm that my understanding of how this will work is

correct, the proposal seems to suggest that future directions definitions
of the bitwise operators will forbid combining bitwise operators in
expressions with arithmetic operators e.g.
     a << b + c
will be illegal because there is no relationship defined between the
additive group and the bitwise groups (when it comes up for review, I will
definitely be opposed to that, but it doesn’t affect my assessment of this

Right, and another discussion will follow.


Just forgive me if I didn't see this but I expect that I

cannot declare an operator belonging to more than one group or compare
to more than one group for precedence (thou I see some situations
being able to asset precedence against more than one group could be

Currently, any operator can belong to only one precedence group.
But one precedence group can contain multiple precedence() comparisons.

It follows from the grammar, but is not mentioned anywhere else.
That was my oversight. I'll try to add it.

By the way, I had asked if some simpler set of tools would suffice, e.g.
parent() instead of precedence().
It seemed that people preferred to have full power of directed graph at
their disposal.
For example, we can insert a precedence group between Additive and

precedencegroup Between {
    precedence(> Additive)
    precedence(< Multiplicative)

And by the way, if Additive and Multiplicative were not connected, this
Between would connect them by transitivity.

- Anton