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
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
https://lists.swift.org/mailman/listinfo/swift-evolution
`b + c * d / e` is not, obviously.
`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).
`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.
Now that I think about it, if job of SE-0077 could be done with a linter,
then... do we still need it?
- Anton
···
2016-06-15 16:00 GMT+03:00 Vladimir.S <svabox@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
https://lists.swift.org/mailman/listinfo/swift-evolution
`b + c * d / e` is not, obviously.
`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).
`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.Now that I think about it, if job of SE-0077 could be done with a linter,
then... do we still need it?
Well, I for one would veer conservative on this one and say that there is a
place for precedence in operators, if only because the mathematical ones
(the majority of them) are commonly used and unambiguous. I think SE-0077
raises some good points. But as to whether `a ?? x + y + z` should be
forced to have parentheses, you have a point here that this might be
territory for a linter.
···
On Wed, Jun 15, 2016 at 8:43 AM, Антон Жилин <swift-evolution@swift.org> wrote:
- Anton
2016-06-15 16:00 GMT+03:00 Vladimir.S <svabox@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
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
`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.
···
On 15.06.2016 16:43, Антон Жилин via swift-evolution wrote:
- Anton
2016-06-15 16:00 GMT+03:00 Vladimir.S <svabox@gmail.com
<mailto:svabox@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>
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
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 <svabox@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 + yIMO 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 <svabox@gmail.com
<mailto:svabox@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>
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Nice points, I also think that unless operators are from the same domain,
more parentheses is better.
I agree. I would, however, advocate for defining 'domains' widely. For
instance, the precedence between comparison operators and arithmetic
operators is unambiguous in mathematics (recall, from your school days if
need be, solving inequalities) and I'd hate to have that lost if someone
deems comparisons to be a different 'domain' from arithmetic.
Other than that, what rules do we need? I can name these:
1. Assignment operators have lower precedence than most operators
Lower than all other operators, I believe
2. Arithmetics has higher precedence than comparative and logical
operators. I don't think that ?? belongs to arithmetics, it's more like
control flow.
I like the point made earlier that ?? is evoking logical operators && and
. I think there are some parallels there worth exploring.
3. Unary operators obviously have higher precedence than everything
I'd add, in addition to the three points above, that the ternary operator
?: (which looks like it will likely stay as such given the commonly
rejected suggestions list) naturally forces itself into a low precedence,
because whatever you can type in between ? and : should naturally have
higher precedence.
> 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"
+1 on that. I'd be very much excited to see the ability to leave undefined
the precedence between two unrelated operators.
Returning to the original problem though, this wouldn't address the problem
that chaining ?? operators is surprising to a lot of people. Should ?? have
no associativity? Are there other ways to address the issue?
···
On Wed, Jun 15, 2016 at 9:53 AM, Антон Жилин <swift-evolution@swift.org> wrote:
- Anton
2016-06-15 17:17 GMT+03:00 Vladimir.S <svabox@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 + yIMO 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 <svabox@gmail.com
<mailto:svabox@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>
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
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
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 everythingI 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 <svabox@gmail.com
<mailto:svabox@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 + yIMO 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 <svabox@gmail.com
<mailto:svabox@gmail.com>
<mailto:svabox@gmail.com <mailto:svabox@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
> 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?) ?
Sorry, I don't see it. The initial question was about chaining of ??
operators. That's a problem with expectations about associativity and not
about precedence, right?
···
On Wed, Jun 15, 2016 at 11:07 AM, Vladimir.S via swift-evolution < swift-evolution@swift.org> wrote:
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 everythingI 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 <svabox@gmail.com
<mailto:svabox@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 + yIMO 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 <svabox@gmail.com
<mailto:svabox@gmail.com>
<mailto:svabox@gmail.com <mailto:svabox@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
Back to associativity, I see nothing wrong with what a ?? b ?? c does.
Analogous constructions are found in Ruby, for example. Right associativity
exists so that we can do lazy evaluation, computing fallback values only
when required. Nothing terrible, again.
- Anton
···
2016-06-15 19:15 GMT+03:00 Xiaodi Wu <xiaodi.wu@gmail.com>:
On Wed, Jun 15, 2016 at 11:07 AM, Vladimir.S via swift-evolution < > swift-evolution@swift.org> wrote:
> 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?) ?Sorry, I don't see it. The initial question was about chaining of ??
operators. That's a problem with expectations about associativity and not
about precedence, right?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 everythingI 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 <svabox@gmail.com
<mailto:svabox@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 + yIMO 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 <svabox@gmail.com
<mailto:svabox@gmail.com>
<mailto:svabox@gmail.com <mailto:svabox@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
> 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?) ?Sorry, I don't see it. The initial question was about chaining of ??
operators. That's a problem with expectations about associativity and not
about precedence, right?
Hmm... The initial question of this thread was about
let result = v1 ?? 0 + v2 ?? 0
Which will resolve to
let result = v1 ?? (0 + v2 ?? 0)
And then the question was raised regarding the ternary operator:
a ? b : c + x + y
So, the question was can we require a parentheses in these cases and if we can, how. I'm not sure if these questions about precedence or associativity.
···
On 15.06.2016 19:15, Xiaodi Wu wrote:
On Wed, Jun 15, 2016 at 11:07 AM, Vladimir.S via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
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 everythingI didn't read se-0077 in details, so have no opinion. Probably
you candescribe 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 <svabox@gmail.com
<mailto:svabox@gmail.com>
<mailto:svabox@gmail.com <mailto:svabox@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 + yIMO 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 <svabox@gmail.com
<mailto:svabox@gmail.com>
<mailto:svabox@gmail.com <mailto:svabox@gmail.com>>
<mailto:svabox@gmail.com <mailto:svabox@gmail.com>
<mailto:svabox@gmail.com <mailto:svabox@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>>
<mailto: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>
<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
I wonder if it's worth it to start a new thread right now.
We could start discussing, what precedence relationships between opeartors
should be, even *before* that proposal is accepted.
If it's rejected though, that discussion is going to trash bin.
- Anton
···
2016-06-15 19:52 GMT+03:00 Антон Жилин <antonyzhilin@gmail.com>:
Back to associativity, I see nothing wrong with what a ?? b ?? c does.
Analogous constructions are found in Ruby, for example. Right associativity
exists so that we can do lazy evaluation, computing fallback values only
when required. Nothing terrible, again.- Anton
2016-06-15 19:15 GMT+03:00 Xiaodi Wu <xiaodi.wu@gmail.com>:
On Wed, Jun 15, 2016 at 11:07 AM, Vladimir.S via swift-evolution < >> swift-evolution@swift.org> wrote:
> 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?) ?Sorry, I don't see it. The initial question was about chaining of ??
operators. That's a problem with expectations about associativity and not
about precedence, right?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 everythingI 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 <svabox@gmail.com
<mailto:svabox@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 + yIMO 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 <svabox@gmail.com
<mailto:svabox@gmail.com>
<mailto:svabox@gmail.com <mailto:svabox@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
We’ve talked about how expressions like `a + b * c / d` aren’t ambiguous
because they are borrowed, in this case from math. The same thing applies
to the ternary conditional: `a ? b : c + x + y`-it too is borrowed (from
the C-type languages) and behaves likewise. There is no need for
parentheses-the only people who will think this is ambiguous is those who
haven’t been introduced to it before.
Well, as I touched on above, I argue that the ternary operator is
constrained to be low precedence because of the syntax itself. Here's why:
* Since it's a single operator, it has only one precedence--that is, to the
extent that it makes sense to think about them separately, ? and : have
equal precedence.
* Imagine the statement `a ? c + x + y : b`. If this statement is to be
syntactically correct, + *must* have higher precedence than ?: because
there is no such thing as `(a ? c) + x + (y : b)`.
* Therefore, by symmetry, `a ? b : c + x + y` must mean `a ? b : (c + x +
y)`.
···
On Wed, Jun 15, 2016 at 1:17 PM, Saagar Jha <saagarjha28@gmail.com> wrote:
IMHO, requiring parentheses would be *more* ambiguous because you’re
breaking precedent, people already know how it should work, without
parentheses. Forcing them to use it breaks their prior knowledge. We don’t
need to hand-hold people who *know* how it works. For those who don’t
know, it’s a simple matter of reading it up (which they would be doing
anyways to learn about it!)As for nil coalescing, it’s visually similar to the ternary operator and
as such has similar behavior. Having a reminder in the Swift guide about
its precedence should be enough, once users have learned it they don’t need
to be reminded every time they use it through a warning.On Wed, Jun 15, 2016 at 11:00 AM Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote:
Maybe wise to wait to see if that proposal is accepted. FWIW, my last
interaction with the core team on operator precedence suggested that they
believed that they had arrived at the correct relative precedence values
and were not receptive to changing them.
On Wed, Jun 15, 2016 at 12:54 Антон Жилин <antonyzhilin@gmail.com> wrote:I wonder if it's worth it to start a new thread right now.
We could start discussing, what precedence relationships between
opeartors should be, even *before* that proposal is accepted.
If it's rejected though, that discussion is going to trash bin.- Anton
2016-06-15 19:52 GMT+03:00 Антон Жилин <antonyzhilin@gmail.com>:
Back to associativity, I see nothing wrong with what a ?? b ?? c
does. Analogous constructions are found in Ruby, for example. Right
associativity exists so that we can do lazy evaluation, computing fallback
values only when required. Nothing terrible, again.- Anton
2016-06-15 19:15 GMT+03:00 Xiaodi Wu <xiaodi.wu@gmail.com>:
On Wed, Jun 15, 2016 at 11:07 AM, Vladimir.S via swift-evolution < >>>>> swift-evolution@swift.org> wrote:
> 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?) ?Sorry, I don't see it. The initial question was about chaining of ??
operators. That's a problem with expectations about associativity and not
about precedence, right?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 everythingI 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 <svabox@gmail.com
<mailto:svabox@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 + yIMO 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 <svabox@gmail.com
<mailto:svabox@gmail.com>
<mailto:svabox@gmail.com <mailto:svabox@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_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution--
-Saagar Jha
Maybe wise to wait to see if that proposal is accepted. FWIW, my last
interaction with the core team on operator precedence suggested that they
believed that they had arrived at the correct relative precedence values
and were not receptive to changing them.
···
On Wed, Jun 15, 2016 at 12:54 Антон Жилин <antonyzhilin@gmail.com> wrote:
I wonder if it's worth it to start a new thread right now.
We could start discussing, what precedence relationships between opeartors
should be, even *before* that proposal is accepted.
If it's rejected though, that discussion is going to trash bin.- Anton
2016-06-15 19:52 GMT+03:00 Антон Жилин <antonyzhilin@gmail.com>:
Back to associativity, I see nothing wrong with what a ?? b ?? c does.
Analogous constructions are found in Ruby, for example. Right associativity
exists so that we can do lazy evaluation, computing fallback values only
when required. Nothing terrible, again.- Anton
2016-06-15 19:15 GMT+03:00 Xiaodi Wu <xiaodi.wu@gmail.com>:
On Wed, Jun 15, 2016 at 11:07 AM, Vladimir.S via swift-evolution < >>> swift-evolution@swift.org> wrote:
> 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?) ?Sorry, I don't see it. The initial question was about chaining of ??
operators. That's a problem with expectations about associativity and not
about precedence, right?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 everythingI 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 <svabox@gmail.com
<mailto:svabox@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 + yIMO 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 <svabox@gmail.com
<mailto:svabox@gmail.com>
<mailto:svabox@gmail.com <mailto:svabox@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
We’ve talked about how expressions like `a + b * c / d` aren’t ambiguous
because they are borrowed, in this case from math. The same thing applies
to the ternary conditional: `a ? b : c + x + y`-it too is borrowed (from
the C-type languages) and behaves likewise. There is no need for
parentheses-the only people who will think this is ambiguous is those who
haven’t been introduced to it before. IMHO, requiring parentheses would be
*more* ambiguous because you’re breaking precedent, people already know how
it should work, without parentheses. Forcing them to use it breaks their
prior knowledge. We don’t need to hand-hold people who *know* how it works.
For those who don’t know, it’s a simple matter of reading it up (which they
would be doing anyways to learn about it!)
As for nil coalescing, it’s visually similar to the ternary operator and as
such has similar behavior. Having a reminder in the Swift guide about its
precedence should be enough, once users have learned it they don’t need to
be reminded every time they use it through a warning.
···
On Wed, Jun 15, 2016 at 11:00 AM Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote:
Maybe wise to wait to see if that proposal is accepted. FWIW, my last
interaction with the core team on operator precedence suggested that they
believed that they had arrived at the correct relative precedence values
and were not receptive to changing them.
On Wed, Jun 15, 2016 at 12:54 Антон Жилин <antonyzhilin@gmail.com> wrote:I wonder if it's worth it to start a new thread right now.
We could start discussing, what precedence relationships between
opeartors should be, even *before* that proposal is accepted.
If it's rejected though, that discussion is going to trash bin.- Anton
2016-06-15 19:52 GMT+03:00 Антон Жилин <antonyzhilin@gmail.com>:
Back to associativity, I see nothing wrong with what a ?? b ?? c does.
Analogous constructions are found in Ruby, for example. Right associativity
exists so that we can do lazy evaluation, computing fallback values only
when required. Nothing terrible, again.- Anton
2016-06-15 19:15 GMT+03:00 Xiaodi Wu <xiaodi.wu@gmail.com>:
On Wed, Jun 15, 2016 at 11:07 AM, Vladimir.S via swift-evolution < >>>> swift-evolution@swift.org> wrote:
> 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?) ?Sorry, I don't see it. The initial question was about chaining of ??
operators. That's a problem with expectations about associativity and not
about precedence, right?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 everythingI 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 <svabox@gmail.com
<mailto:svabox@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 + yIMO 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 <svabox@gmail.com
<mailto:svabox@gmail.com>
<mailto:svabox@gmail.com <mailto:svabox@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_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
--
-Saagar Jha
What do you think about arithmetic and bitwise operators? Arithmetic and
casting? Should they have defined precedence?
- Anton
···
2016-06-15 21:17 GMT+03:00 Saagar Jha <saagarjha28@gmail.com>:
We’ve talked about how expressions like `a + b * c / d` aren’t ambiguous
because they are borrowed, in this case from math. The same thing applies
to the ternary conditional: `a ? b : c + x + y`-it too is borrowed (from
the C-type languages) and behaves likewise. There is no need for
parentheses-the only people who will think this is ambiguous is those who
haven’t been introduced to it before. IMHO, requiring parentheses would be
*more* ambiguous because you’re breaking precedent, people already know
how it should work, without parentheses. Forcing them to use it breaks
their prior knowledge. We don’t need to hand-hold people who *know* how
it works. For those who don’t know, it’s a simple matter of reading it up
(which they would be doing anyways to learn about it!)As for nil coalescing, it’s visually similar to the ternary operator and
as such has similar behavior. Having a reminder in the Swift guide about
its precedence should be enough, once users have learned it they don’t need
to be reminded every time they use it through a warning.On Wed, Jun 15, 2016 at 11:00 AM Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote:
Maybe wise to wait to see if that proposal is accepted. FWIW, my last
interaction with the core team on operator precedence suggested that they
believed that they had arrived at the correct relative precedence values
and were not receptive to changing them.
On Wed, Jun 15, 2016 at 12:54 Антон Жилин <antonyzhilin@gmail.com> wrote:I wonder if it's worth it to start a new thread right now.
We could start discussing, what precedence relationships between
opeartors should be, even *before* that proposal is accepted.
If it's rejected though, that discussion is going to trash bin.- Anton
2016-06-15 19:52 GMT+03:00 Антон Жилин <antonyzhilin@gmail.com>:
Back to associativity, I see nothing wrong with what a ?? b ?? c
does. Analogous constructions are found in Ruby, for example. Right
associativity exists so that we can do lazy evaluation, computing fallback
values only when required. Nothing terrible, again.- Anton
2016-06-15 19:15 GMT+03:00 Xiaodi Wu <xiaodi.wu@gmail.com>:
On Wed, Jun 15, 2016 at 11:07 AM, Vladimir.S via swift-evolution < >>>>> swift-evolution@swift.org> wrote:
> 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?) ?Sorry, I don't see it. The initial question was about chaining of ??
operators. That's a problem with expectations about associativity and not
about precedence, right?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 everythingI 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 <svabox@gmail.com
<mailto:svabox@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 + yIMO 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 <svabox@gmail.com
<mailto:svabox@gmail.com>
<mailto:svabox@gmail.com <mailto:svabox@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_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution--
-Saagar Jha
Yes. They’re all operators we know about already, and the same argument
applies. Just like you wouldn’t change + to have a higher precedence than
*, bitwise operators already have their own, uniform precedences. I can’t
see any reason not to have one, other than confusion from those who aren’t
completely sure how they function-in which case they’re better of taking a
look at the docs (or Quick Help, as another thread suggests) to learn how
they work.
FYI, the relative precedence of arithmetic and bitwise operators is not the
same across languages in the C family. Here, Swift diverges from C and
resembles Go. I raised this point some time ago and was told in no
uncertain terms by the core team that it was intentional and that they were
satisfied with the result.
···
On Wed, Jun 15, 2016 at 1:31 PM, Saagar Jha <saagarjha28@gmail.com> wrote:
On Wed, Jun 15, 2016 at 11:23 AM Антон Жилин <antonyzhilin@gmail.com> > wrote:
What do you think about arithmetic and bitwise operators? Arithmetic and
casting? Should they have defined precedence?- Anton
2016-06-15 21:17 GMT+03:00 Saagar Jha <saagarjha28@gmail.com>:
We’ve talked about how expressions like `a + b * c / d` aren’t ambiguous
because they are borrowed, in this case from math. The same thing applies
to the ternary conditional: `a ? b : c + x + y`-it too is borrowed (from
the C-type languages) and behaves likewise. There is no need for
parentheses-the only people who will think this is ambiguous is those who
haven’t been introduced to it before. IMHO, requiring parentheses would be
*more* ambiguous because you’re breaking precedent, people already know
how it should work, without parentheses. Forcing them to use it breaks
their prior knowledge. We don’t need to hand-hold people who *know* how
it works. For those who don’t know, it’s a simple matter of reading it up
(which they would be doing anyways to learn about it!)As for nil coalescing, it’s visually similar to the ternary operator and
as such has similar behavior. Having a reminder in the Swift guide about
its precedence should be enough, once users have learned it they don’t need
to be reminded every time they use it through a warning.On Wed, Jun 15, 2016 at 11:00 AM Xiaodi Wu via swift-evolution < >>> swift-evolution@swift.org> wrote:
Maybe wise to wait to see if that proposal is accepted. FWIW, my last
interaction with the core team on operator precedence suggested that they
believed that they had arrived at the correct relative precedence values
and were not receptive to changing them.
On Wed, Jun 15, 2016 at 12:54 Антон Жилин <antonyzhilin@gmail.com> >>>> wrote:I wonder if it's worth it to start a new thread right now.
We could start discussing, what precedence relationships between
opeartors should be, even *before* that proposal is accepted.
If it's rejected though, that discussion is going to trash bin.- Anton
2016-06-15 19:52 GMT+03:00 Антон Жилин <antonyzhilin@gmail.com>:
Back to associativity, I see nothing wrong with what a ?? b ?? c
does. Analogous constructions are found in Ruby, for example. Right
associativity exists so that we can do lazy evaluation, computing fallback
values only when required. Nothing terrible, again.- Anton
2016-06-15 19:15 GMT+03:00 Xiaodi Wu <xiaodi.wu@gmail.com>:
On Wed, Jun 15, 2016 at 11:07 AM, Vladimir.S via swift-evolution < >>>>>>> swift-evolution@swift.org> wrote:
> 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?) ?Sorry, I don't see it. The initial question was about chaining of ??
operators. That's a problem with expectations about associativity and not
about precedence, right?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 everythingI 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 <svabox@gmail.com
<mailto:svabox@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 + yIMO 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 <svabox@gmail.com
<mailto:svabox@gmail.com>
<mailto:svabox@gmail.com <mailto:svabox@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_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution--
-Saagar Jha--
-Saagar Jha
I was asking about only bitwise operators, but the reply was more general.
One reply from Chris Lattner:
···
On Feb 13, 2016, at 6:32 AM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote:
>
> Not sure if this is intentional, a bug, and/or a topic for evolution:
>
> In Swift, bitwise operators seem to have a different precedence in
> relation to other operators than they do in (all other?) C-family
> languages, at least per documentation.
Yep, this is true, and this is intentional. Swift has a greatly
simplified and rationalized set of precedences, and yes, that means they
differ from C.
On Wed, Jun 15, 2016 at 1:46 PM, Saagar Jha <saagarjha28@gmail.com> wrote:
On Wed, Jun 15, 2016 at 11:36 AM Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
On Wed, Jun 15, 2016 at 1:31 PM, Saagar Jha <saagarjha28@gmail.com> >> wrote:
Yes. They’re all operators we know about already, and the same argument
applies. Just like you wouldn’t change + to have a higher precedence than
*, bitwise operators already have their own, uniform precedences. I can’t
see any reason not to have one, other than confusion from those who aren’t
completely sure how they function-in which case they’re better of taking a
look at the docs (or Quick Help, as another thread suggests) to learn how
they work.FYI, the relative precedence of arithmetic and bitwise operators is not
the same across languages in the C family. Here, Swift diverges from C and
resembles Go. I raised this point some time ago and was told in no
uncertain terms by the core team that it was intentional and that they were
satisfied with the result.Is the core team talking only for bitwise operators or all of them?
On Wed, Jun 15, 2016 at 11:23 AM Антон Жилин <antonyzhilin@gmail.com> >>> wrote:
What do you think about arithmetic and bitwise operators? Arithmetic
and casting? Should they have defined precedence?- Anton
2016-06-15 21:17 GMT+03:00 Saagar Jha <saagarjha28@gmail.com>:
We’ve talked about how expressions like `a + b * c / d` aren’t
ambiguous because they are borrowed, in this case from math. The same thing
applies to the ternary conditional: `a ? b : c + x + y`-it too is borrowed
(from the C-type languages) and behaves likewise. There is no need for
parentheses-the only people who will think this is ambiguous is those who
haven’t been introduced to it before. IMHO, requiring parentheses would be
*more* ambiguous because you’re breaking precedent, people already
know how it should work, without parentheses. Forcing them to use it breaks
their prior knowledge. We don’t need to hand-hold people who *know* how
it works. For those who don’t know, it’s a simple matter of reading it up
(which they would be doing anyways to learn about it!)As for nil coalescing, it’s visually similar to the ternary operator
and as such has similar behavior. Having a reminder in the Swift guide
about its precedence should be enough, once users have learned it they
don’t need to be reminded every time they use it through a warning.On Wed, Jun 15, 2016 at 11:00 AM Xiaodi Wu via swift-evolution < >>>>> swift-evolution@swift.org> wrote:
Maybe wise to wait to see if that proposal is accepted. FWIW, my last
interaction with the core team on operator precedence suggested that they
believed that they had arrived at the correct relative precedence values
and were not receptive to changing them.
On Wed, Jun 15, 2016 at 12:54 Антон Жилин <antonyzhilin@gmail.com> >>>>>> wrote:I wonder if it's worth it to start a new thread right now.
We could start discussing, what precedence relationships between
opeartors should be, even *before* that proposal is accepted.
If it's rejected though, that discussion is going to trash bin.- Anton
2016-06-15 19:52 GMT+03:00 Антон Жилин <antonyzhilin@gmail.com>:
Back to associativity, I see nothing wrong with what a ?? b ?? c
does. Analogous constructions are found in Ruby, for example. Right
associativity exists so that we can do lazy evaluation, computing fallback
values only when required. Nothing terrible, again.- Anton
2016-06-15 19:15 GMT+03:00 Xiaodi Wu <xiaodi.wu@gmail.com>:
On Wed, Jun 15, 2016 at 11:07 AM, Vladimir.S via swift-evolution < >>>>>>>>> swift-evolution@swift.org> wrote:
> 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?) ?Sorry, I don't see it. The initial question was about chaining of
?? operators. That's a problem with expectations about associativity and
not about precedence, right?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
everythingI 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 <svabox@gmail.com
<mailto:svabox@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 + yIMO 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 <svabox@gmail.com
<mailto:svabox@gmail.com>
<mailto:svabox@gmail.com <mailto:svabox@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_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution--
-Saagar Jha--
-Saagar Jha
--
-Saagar Jha
Yes. They’re all operators we know about already, and the same argument
applies. Just like you wouldn’t change + to have a higher precedence than
*, bitwise operators already have their own, uniform precedences. I can’t
see any reason not to have one, other than confusion from those who aren’t
completely sure how they function-in which case they’re better of taking a
look at the docs (or Quick Help, as another thread suggests) to learn how
they work.
···
On Wed, Jun 15, 2016 at 11:23 AM Антон Жилин <antonyzhilin@gmail.com> wrote:
What do you think about arithmetic and bitwise operators? Arithmetic and
casting? Should they have defined precedence?- Anton
2016-06-15 21:17 GMT+03:00 Saagar Jha <saagarjha28@gmail.com>:
We’ve talked about how expressions like `a + b * c / d` aren’t ambiguous
because they are borrowed, in this case from math. The same thing applies
to the ternary conditional: `a ? b : c + x + y`-it too is borrowed (from
the C-type languages) and behaves likewise. There is no need for
parentheses-the only people who will think this is ambiguous is those who
haven’t been introduced to it before. IMHO, requiring parentheses would be
*more* ambiguous because you’re breaking precedent, people already know
how it should work, without parentheses. Forcing them to use it breaks
their prior knowledge. We don’t need to hand-hold people who *know* how
it works. For those who don’t know, it’s a simple matter of reading it up
(which they would be doing anyways to learn about it!)As for nil coalescing, it’s visually similar to the ternary operator and
as such has similar behavior. Having a reminder in the Swift guide about
its precedence should be enough, once users have learned it they don’t need
to be reminded every time they use it through a warning.On Wed, Jun 15, 2016 at 11:00 AM Xiaodi Wu via swift-evolution < >> swift-evolution@swift.org> wrote:
Maybe wise to wait to see if that proposal is accepted. FWIW, my last
interaction with the core team on operator precedence suggested that they
believed that they had arrived at the correct relative precedence values
and were not receptive to changing them.
On Wed, Jun 15, 2016 at 12:54 Антон Жилин <antonyzhilin@gmail.com> >>> wrote:I wonder if it's worth it to start a new thread right now.
We could start discussing, what precedence relationships between
opeartors should be, even *before* that proposal is accepted.
If it's rejected though, that discussion is going to trash bin.- Anton
2016-06-15 19:52 GMT+03:00 Антон Жилин <antonyzhilin@gmail.com>:
Back to associativity, I see nothing wrong with what a ?? b ?? c
does. Analogous constructions are found in Ruby, for example. Right
associativity exists so that we can do lazy evaluation, computing fallback
values only when required. Nothing terrible, again.- Anton
2016-06-15 19:15 GMT+03:00 Xiaodi Wu <xiaodi.wu@gmail.com>:
On Wed, Jun 15, 2016 at 11:07 AM, Vladimir.S via swift-evolution < >>>>>> swift-evolution@swift.org> wrote:
> 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?) ?Sorry, I don't see it. The initial question was about chaining of ??
operators. That's a problem with expectations about associativity and not
about precedence, right?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 everythingI 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 <svabox@gmail.com
<mailto:svabox@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 + yIMO 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 <svabox@gmail.com
<mailto:svabox@gmail.com>
<mailto:svabox@gmail.com <mailto:svabox@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_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution--
-Saagar Jha--
-Saagar Jha
Yes. They’re all operators we know about already, and the same argument
applies. Just like you wouldn’t change + to have a higher precedence than
*, bitwise operators already have their own, uniform precedences. I can’t
see any reason not to have one, other than confusion from those who aren’t
completely sure how they function-in which case they’re better of taking a
look at the docs (or Quick Help, as another thread suggests) to learn how
they work.FYI, the relative precedence of arithmetic and bitwise operators is not
the same across languages in the C family. Here, Swift diverges from C and
resembles Go. I raised this point some time ago and was told in no
uncertain terms by the core team that it was intentional and that they were
satisfied with the result.
Is the core team talking only for bitwise operators or all of them?
What do you think about arithmetic and bitwise operators? Arithmetic and
casting? Should they have defined precedence?- Anton
We’ve talked about how expressions like `a + b * c / d` aren’t
ambiguous because they are borrowed, in this case from math. The same thing
applies to the ternary conditional: `a ? b : c + x + y`-it too is borrowed
(from the C-type languages) and behaves likewise. There is no need for
parentheses-the only people who will think this is ambiguous is those who
haven’t been introduced to it before. IMHO, requiring parentheses would be
*more* ambiguous because you’re breaking precedent, people already
know how it should work, without parentheses. Forcing them to use it breaks
their prior knowledge. We don’t need to hand-hold people who *know* how
it works. For those who don’t know, it’s a simple matter of reading it up
(which they would be doing anyways to learn about it!)As for nil coalescing, it’s visually similar to the ternary operator
and as such has similar behavior. Having a reminder in the Swift guide
about its precedence should be enough, once users have learned it they
don’t need to be reminded every time they use it through a warning.Maybe wise to wait to see if that proposal is accepted. FWIW, my last
interaction with the core team on operator precedence suggested that they
believed that they had arrived at the correct relative precedence values
and were not receptive to changing them.I wonder if it's worth it to start a new thread right now.
We could start discussing, what precedence relationships between
opeartors should be, even *before* that proposal is accepted.
If it's rejected though, that discussion is going to trash bin.- Anton
Back to associativity, I see nothing wrong with what a ?? b ?? c
does. Analogous constructions are found in Ruby, for example. Right
associativity exists so that we can do lazy evaluation, computing fallback
values only when required. Nothing terrible, again.- Anton
> 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?) ?Sorry, I don't see it. The initial question was about chaining of
?? operators. That's a problem with expectations about associativity and
not about precedence, right?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.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
everythingI 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 <svabox@gmail.com
<mailto:svabox@gmail.com>>:`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 + yIMO 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 <svabox@gmail.com
<mailto:svabox@gmail.com>
<mailto:svabox@gmail.com <mailto:svabox@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" ?
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_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution--
-Saagar Jha--
-Saagar Jha
--
-Saagar Jha
···
On Wed, Jun 15, 2016 at 11:36 AM Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
On Wed, Jun 15, 2016 at 1:31 PM, Saagar Jha <saagarjha28@gmail.com> wrote:
On Wed, Jun 15, 2016 at 11:23 AM Антон Жилин <antonyzhilin@gmail.com> >> wrote:
2016-06-15 21:17 GMT+03:00 Saagar Jha <saagarjha28@gmail.com>:
On Wed, Jun 15, 2016 at 11:00 AM Xiaodi Wu via swift-evolution < >>>> swift-evolution@swift.org> wrote:
On Wed, Jun 15, 2016 at 12:54 Антон Жилин <antonyzhilin@gmail.com> >>>>> wrote:
2016-06-15 19:52 GMT+03:00 Антон Жилин <antonyzhilin@gmail.com>:
2016-06-15 19:15 GMT+03:00 Xiaodi Wu <xiaodi.wu@gmail.com>:
On Wed, Jun 15, 2016 at 11:07 AM, Vladimir.S via swift-evolution < >>>>>>>> swift-evolution@swift.org> wrote:
On 15.06.2016 17:53, Антон Жилин wrote:
On 15.06.2016 16:43, Антон Жилин via swift-evolution wrote:
On 15.06.2016 15:42, Антон Жилин via swift-evolution >>>>>>>>>> wrote: