Open kevin-dp opened 6 years ago
Yeah this is expected. All the forms that MDN calls precedence 19 (static/computed member access, new
, call) are not really operators in the sense that Sweet understands. This is because they all have grammar restrictions that make them more specialized than a normal binary/unary operator and so expand "below" the level of Sweet's operator precedence rules.
Ok, that's a pitty. But, why doesn't my first attempt compile, whereas my second attempt does?
I want to define an operator
>>=
which performs member access (i.e. is equivalent to.
).My first attempt does not compile:
My second attempt (using computed member access) works but not as expected:
I deliberately give my
>>=
operator precedence 19, which is the same precedence as javascript's member access operator (see JS operator precedence).Based on the given precedence i would expect this to be possible:
However, this does not compile. For some reason the
right
argument of my>>=
operator is a call expression (i.e.foo.then(...)
).So, based on the given precedence i would expect
obj>>=foo.then(...)
to be equivalent to(obj>>=foo).then(...)
, however it seems to be interpreted asobj>>=(foo.then(...))
.If i manually add the parentheses as follows
(obj>>=foo).then(...)
, then it works.