& and => should not be an operator but a keyword instead
From the document, the precedence of current operators is &>*>:=>=>.
However, ,&a:=5 will run a:=5 first and then Reference &.
Also, f()=>this.xx:=7 will run := first, but f2:=ths=>5 will run => first instead.
All of them above are against the precedence rules. Therefore, considering the complexity, & and => should be treated as keywords rather than operators.
[V2:] & and => should not be an operator but a keyword instead
Re: [V2:] & and => should not be an operator but a keyword instead
Wouldn't those things you have in mind be explained by the details in the ":=" documentation?
Re: [V2:] & and => should not be an operator but a keyword instead
But the document didn't say about the &. At least haven't been found currently.
Both situations are against the operator precedence. And the particular case of & hasn't been documented yet.
Once the particular case of & is documented, I guess it will be removed from the operator list and become normal keywords.
Re: [V2:] & and => should not be an operator but a keyword instead
The suggestion to call & or => a keyword doesn't make sense on any level. A keyword is just a word with special meaning. & and => are combinations of symbols; they are not words. and, or and not are both keywords and operators, and are affected by operator precedence. if, local and as are keywords but not operators. & is an operator, and is affected by operator precedence like any other prefix operator.
Whether it is or isn't an "operator" and is or isn't a "keyword" does not imply anything about precedence.
:= overrides precedence. This is explained in the documentation. There is nothing at all special about the combination of & with :=, so no reason to mention & in particular.
=> could be said to override precedence in the same way as :=; i.e. it has higher precedence than anything to its left. This isn't explained anywhere, but interpreting a ?? b => c as (a ?? b) => c obviously wouldn't make any sense, just as it wouldn't make sense to interpret a + b(c) as (a + b)(c). It could be placed under "The following types of sub-expressions override precedence/order of evaluation" instead.
The documentation tells you that the parentheses around the parameter list of => can only be omitted when "the parameter list consists of only a single parameter name", which implies that any operator to the left of the parameter name is not part of the parameter list and therefore not part of the => function. That's also common sense, anyway.
Whether it is or isn't an "operator" and is or isn't a "keyword" does not imply anything about precedence.
:= overrides precedence. This is explained in the documentation. There is nothing at all special about the combination of & with :=, so no reason to mention & in particular.
=> could be said to override precedence in the same way as :=; i.e. it has higher precedence than anything to its left. This isn't explained anywhere, but interpreting a ?? b => c as (a ?? b) => c obviously wouldn't make any sense, just as it wouldn't make sense to interpret a + b(c) as (a + b)(c). It could be placed under "The following types of sub-expressions override precedence/order of evaluation" instead.
The documentation tells you that the parentheses around the parameter list of => can only be omitted when "the parameter list consists of only a single parameter name", which implies that any operator to the left of the parameter name is not part of the parameter list and therefore not part of the => function. That's also common sense, anyway.
Return to “Suggestions on Documentation Improvements”
Who is online
Users browsing this forum: No registered users and 17 guests