> If precedence between two operators is undefined, we cannot omit
> parentheses.
Hm.. Probably the initial problem could be solved with this? I.e. if we'll
have *no* defined precedence between math operators and between ?? and
between ?: (and probably something else?) ?
As for rules of precedence, I think it is really not important what
precedence will be assigned for ??/?: as in any case IMO most devs will not
remember this for sure in situation when one need to write/read such
complex expression.
For me, probably I have some extreme opinion: if we have a mix of operators
from different domains (math and ?? for example) we need parentheses to
exclude any kind of ambiguity.
On 15.06.2016 17:53, Антон Жилин wrote:
Nice points, I also think that unless operators are from the same domain,
more parentheses is better.
Other than that, what rules do we need? I can name these:
1. Assignment operators have lower precedence than most operators
2. Arithmetics has higher precedence than comparative and logical
operators. I don't think that ?? belongs to arithmetics, it's more like
control flow.
3. Unary operators obviously have higher precedence than everything
I didn't read se-0077 in details, so have no opinion. Probably you can
describe main ideas of it here in two words.
Replace numeric precedence with precedence relationships between pairs of
operators. If precedence between two operators is undefined, we cannot omit
parentheses.
My thought was basically: "parentheses between some operators must be
enforced by the language" <=> "SE-0077 is needed"
- Anton
2016-06-15 17:17 GMT+03:00 Vladimir.S <sva...@gmail.com
<mailto:sva...@gmail.com>>:
On 15.06.2016 16:43, Антон Жилин via swift-evolution wrote:
`b + c * d / e` is not, obviously.
obviously, for math operators it seems like we don't need any
clarifications
`a ? b : c + x + y` -- I'd also say not, because, well, it's ternary
operator, the special case that everyone should know (otherwise it
looks
like a mess with ? and : operators).
Yes, it's ternary operator. But is it
a ? b : (c + x + y)
or
(a ? b : c) + x + y
IMO ambiguous.
`a ?? x + y + z` -- maybe. If not for analogies with || and && and
knowing
about @autoclosure, I'd say that priority of ?? should be very high.
The same, is it
a ?? (x + y + z)
or
(a ?? x) + y + z
? I.e. I'm not asking, just show that the question is not if we know
what does ?? mean, but how all the expression will be treated.
IMO it's totally false assumption that most of developers(and poor
beginners) do remember the the correct precedence in such expressions
and in most cases will not make a bug and so we should not require the
parentheses. Imagine how each such expression will be crystal clear
about the order of processing in *any* Swift source code you could find
anywhere. IMO this will be great advantage of the language.
Now that I think about it, if job of SE-0077 could be done with a
linter,
then... do we still need it?
I didn't read se-0077 in details, so have no opinion. Probably you can
describe main ideas of it here in two words.
- Anton
2016-06-15 16:00 GMT+03:00 Vladimir.S <sva...@gmail.com
<mailto:sva...@gmail.com>
<mailto:sva...@gmail.com <mailto:sva...@gmail.com>>>:
As I understand, the question is if
`a ?? x + y + z`
and
`a ? b : c + x + y`
(or `b + c * d / e`)
an "ambiguous case" ?
On 15.06.2016 15:42, Антон Жилин via swift-evolution wrote:
It's tempting to mention SE-0077 in this context. If it's
accepted,
we will
be able to make omission of parentheses an error in
ambiguous cases.
- Anton
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
<mailto:swift-evolution@swift.org>
<mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
