Nil coalescing operator precedence

Evolution Discussion
1

Nil coalescing operator has very low precedence and it's very easy to forget the parentheses.
It's tempting to write something like this:

let result = v1 ?? 0 + v2 ?? 0

Which will resolve to

let result = v1 ?? (0 + v2 ?? 0)

An example of incorrect code from real project which went unnoticed for some time:

let allParameters: [String: Any?] =
  defaultParameters["sendMessage"] ?? [:] +
  parameters +
  ["chat_id": chat_id, "text": text]

Unlike ternary operator I can hardly think of a case when someone would want to use ?? in expression like:
a + b ?? c + d meaning (a + b) ?? (c + d)

This seems to be a source of errors in other languages as well, for example:

I propose to consider raising it's precedence or requiring parentheses if ?? is used with multiple statements.

···

--
Andrey Fidrya

2

+1 on this.

···

On Jun 12, 2016, at 8:01 AM, Andrey Fidrya via swift-evolution <swift-evolution@swift.org> wrote:

Nil coalescing operator has very low precedence and it's very easy to forget the parentheses.
It's tempting to write something like this:

let result = v1 ?? 0 + v2 ?? 0

Which will resolve to

let result = v1 ?? (0 + v2 ?? 0)

An example of incorrect code from real project which went unnoticed for some time:

let allParameters: [String: Any?] =
defaultParameters["sendMessage"] ?? [:] +
parameters +
["chat_id": chat_id, "text": text]

Unlike ternary operator I can hardly think of a case when someone would want to use ?? in expression like:
a + b ?? c + d meaning (a + b) ?? (c + d)

This seems to be a source of errors in other languages as well, for example:
Beware: The null-coalescing (??) operator is low in the order of operator precedence. - CodeProject

I propose to consider raising it's precedence or requiring parentheses if ?? is used with multiple statements.

--
Andrey Fidrya

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

3

Nil coalescing operator has very low precedence and it's very easy to forget the parentheses.
It's tempting to write something like this:

let result = v1 ?? 0 + v2 ?? 0

Which will resolve to

let result = v1 ?? (0 + v2 ?? 0)

This is how I would expected the operator to work.

This seems to be a source of errors in other languages as well, for example:
Beware: The null-coalescing (??) operator is low in the order of operator precedence. - CodeProject

I propose to consider raising it's precedence or requiring parentheses if ?? is used with multiple statements.

I like the idea of requiring parenthesis (or at least having a warning)
on ambiguous lines with two `??`.

···

On Sun, Jun 12 2016 at 02:01:17 AM, Andrey Fidrya via swift-evolution <swift-evolution@swift.org> wrote:

--
Roth

4

I've given it some more thought... Even expressions with single ?? can be confusing.
For example:

1)

let z = a ?? x + y + z

Actually it's
let z = a ?? (x + y + z)

But can be mistakenly interpreted as
let z = (a ?? x) + y + z

2) Same problem with ?:

let z = a ? b : c + x + y

It's
let z = a ? b : (c + x + y)

Not
let z = (a ? b : c) + x + y

Possibly warnings should be shown in both these cases. Or is it too extreme?

···

--
Andrey Fidrya

On 15 Jun 2016, at 01:08, Roth Michaels via swift-evolution <swift-evolution@swift.org> wrote:

On Sun, Jun 12 2016 at 02:01:17 AM, Andrey Fidrya via swift-evolution <swift-evolution@swift.org> wrote:

Nil coalescing operator has very low precedence and it's very easy to forget the parentheses.
It's tempting to write something like this:

let result = v1 ?? 0 + v2 ?? 0

Which will resolve to

let result = v1 ?? (0 + v2 ?? 0)

This is how I would expected the operator to work.

This seems to be a source of errors in other languages as well, for example:
Beware: The null-coalescing (??) operator is low in the order of operator precedence. - CodeProject

I propose to consider raising it's precedence or requiring parentheses if ?? is used with multiple statements.

I like the idea of requiring parenthesis (or at least having a warning)
on ambiguous lines with two `??`.

--
Roth

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

5

This is an orthogonal issue to the first that you identified. The first has
to do with the associativity of the operator, the second has to do with the
precedence of the operator.

I think there's sufficient confusion about the first that it's worth
addressing. However, with respect to precedence, at the end of the day
every operator has to have a precedence. Since ?? and ?: have no
counterparts in math, there's no reason that a new user would know whether
the precedence is higher or lower than that of arithmetic operators. It's
simply listed in a table.

I don't know that it's feasible to warn on every use of operators with
mixed precedence. Doing so would effectively do away with the concept of
precedence at all, since everything would have to be grouped by parentheses
in order to avoid warnings. (The core team has been pretty clear that there
will be no 'optional' warnings, and in certain organizations warnings are
regarded as errors.)

···

On Tue, Jun 14, 2016 at 17:50 Andrey Fidrya via swift-evolution < swift-evolution@swift.org> wrote:

I've given it some more thought... Even expressions with single ?? can be
confusing.
For example:

1)

let z = a ?? x + y + z

Actually it's
let z = a ?? (x + y + z)

But can be mistakenly interpreted as
let z = (a ?? x) + y + z

2) Same problem with ?:

let z = a ? b : c + x + y

It's
let z = a ? b : (c + x + y)

Not
let z = (a ? b : c) + x + y

Possibly warnings should be shown in both these cases. Or is it too
extreme?

--
Andrey Fidrya

On 15 Jun 2016, at 01:08, Roth Michaels via swift-evolution < > swift-evolution@swift.org> wrote:

On Sun, Jun 12 2016 at 02:01:17 AM, Andrey Fidrya via swift-evolution < > swift-evolution@swift.org> wrote:

Nil coalescing operator has very low precedence and it's very easy to
forget the parentheses.
It's tempting to write something like this:

let result = v1 ?? 0 + v2 ?? 0

Which will resolve to

let result = v1 ?? (0 + v2 ?? 0)

This is how I would expected the operator to work.

This seems to be a source of errors in other languages as well, for
example:

http://www.codeproject.com/Tips/721145/Beware-The-null-coalescing-operator-is-low-in-the

I propose to consider raising it's precedence or requiring parentheses if
?? is used with multiple statements.

I like the idea of requiring parenthesis (or at least having a warning)
on ambiguous lines with two `??`.

--
Roth

_______________________________________________
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

1 Like
6

Personally I’m against precedence entirely, as I’m terrible at remembering the order and even if I could I’d still see myself making tons of mistakes, as a result I use parenthesis in all but the simplest statements just to be absolutely clear. The problem with precedence is that while it lets the compiler choose a logical order to process expressions, you can never be sure that it’s actually the order the user intended.

Still, I may be in the minority, not sure, maybe other people are happier with math operator precedence than I am. However, I think that effectively forcing parenthesis on ?? and ?: may be okay; most of the time these are used in simple, non-ambiguous cases (either on their own, or with an assignment), so parenthesis shouldn’t be needed, but anywhere they’re within larger statements I think it makes sense to encourage parenthesis use so the compiler can be certain it isn’t guessing at your meaning. I mean it’s kind of like forcing a defensive coding style, but that’s not necessarily a bad thing; I’ve learned from experience that I suck at operator precedence and instead of wasting time looking it up to be sure, hurling a bunch of parenthesis in place not only clarifies my intent, but avoids the problem entirely, I wish more people would do it, as I still run into cases in other people’s code where it takes some time to figure out meaning (usually because these operator precedence obsessed monsters don’t leave comments either ;)

Increasing the precedence won’t help IMO, as it remains just as possible for a user to make a mistake, plus we run the risk of changing the result of currently correct code that works fine with the current precedence but will suddenly give different results if evaluated sooner.

So yeah, I think recommending parenthesis is a good compromise, and good style to encourage when using these operators in more complex cases, not just for avoiding mistakes but also to make the code more readable for others.

···

On 15 Jun 2016, at 00:21, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:
I don't know that it's feasible to warn on every use of operators with mixed precedence. Doing so would effectively do away with the concept of precedence at all, since everything would have to be grouped by parentheses in order to avoid warnings. (The core team has been pretty clear that there will be no 'optional' warnings, and in certain organizations warnings are regarded as errors.)

7

Personally I’m against precedence entirely, as I’m terrible at remembering the order and even if I could I’d still see myself making tons of mistakes, as a result I use parenthesis in all but the simplest statements just to be absolutely clear. The problem with precedence is that while it lets the compiler choose a logical order to process expressions, you can never be sure that it’s actually the order the user intended.

Still, I may be in the minority, not sure, maybe other people are happier with math operator precedence than I am. However, I think that effectively forcing parenthesis on ?? and ?: may be okay; most of the time these are used in simple, non-ambiguous cases (either on their own, or with an assignment), so parenthesis shouldn’t be needed, but anywhere they’re within larger statements I think it makes sense to encourage parenthesis use so the compiler can be certain it isn’t guessing at your meaning. I mean it’s kind of like forcing a defensive coding style, but that’s not necessarily a bad thing; I’ve learned from experience that I suck at operator precedence and instead of wasting time looking it up to be sure, hurling a bunch of parenthesis in place not only clarifies my intent, but avoids the problem entirely, I wish more people would do it, as I still run into cases in other people’s code where it takes some time to figure out meaning (usually because these operator precedence obsessed monsters don’t leave comments either ;)

Increasing the precedence won’t help IMO, as it remains just as possible for a user to make a mistake, plus we run the risk of changing the result of currently correct code that works fine with the current precedence but will suddenly give different results if evaluated sooner.

So yeah, I think recommending parenthesis is a good compromise, and good style to encourage when using these operators in more complex cases, not just for avoiding mistakes but also to make the code more readable for others.

···

On 15 Jun 2016, at 00:21, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:
I don't know that it's feasible to warn on every use of operators with mixed precedence. Doing so would effectively do away with the concept of precedence at all, since everything would have to be grouped by parentheses in order to avoid warnings. (The core team has been pretty clear that there will be no 'optional' warnings, and in certain organizations warnings are regarded as errors.)

8

I agree, precedence should be left for math operations that are known by all. Since this is not a normal operation, it should be left up to the developer to tell the computer what to do. The computer should not assume for you how to handle complex operations next to a nil coalescing operator.

I am intrigued with the idea of explaining to the developer what the order of their current code will run. Almost like a hint or warning. If there was a feature in Xcode that explained the order of operations for a given line of code, this would help the developer choose where to put parenthesis. But, I don’t believe we should suggest where the parenthesis go (this becomes another assumption on how they want their code to be). Misaligned assumptions can frustrate the developer and slow down their coding or confuse them more.

What does everyone think about adding a visual explanation with the order of operations in a formula.

Example:

var a = b + c * d / e

Visual Hint (maybe popup like Quick Help or something simpler)

var a = (b + ((c * d) / e))

Or

var x = c * d
var y = x / e
var z = b + y

Some way to quickly represent the order to inform a developer of the current order.

I believe there needs to be more communication between the developer and the computer. An open dialog about what the developer is trying to tell the computer to do. If the computer says “this is what I think you are telling me to do”, the developer then can decide if they wrote the correct line of code.

Thanks,
Jo

···

On Jun 15, 2016, at 4:31 AM, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:

On 15 Jun 2016, at 00:21, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:
I don't know that it's feasible to warn on every use of operators with mixed precedence. Doing so would effectively do away with the concept of precedence at all, since everything would have to be grouped by parentheses in order to avoid warnings. (The core team has been pretty clear that there will be no 'optional' warnings, and in certain organizations warnings are regarded as errors.)

Personally I’m against precedence entirely, as I’m terrible at remembering the order and even if I could I’d still see myself making tons of mistakes, as a result I use parenthesis in all but the simplest statements just to be absolutely clear. The problem with precedence is that while it lets the compiler choose a logical order to process expressions, you can never be sure that it’s actually the order the user intended.

Still, I may be in the minority, not sure, maybe other people are happier with math operator precedence than I am. However, I think that effectively forcing parenthesis on ?? and ?: may be okay; most of the time these are used in simple, non-ambiguous cases (either on their own, or with an assignment), so parenthesis shouldn’t be needed, but anywhere they’re within larger statements I think it makes sense to encourage parenthesis use so the compiler can be certain it isn’t guessing at your meaning. I mean it’s kind of like forcing a defensive coding style, but that’s not necessarily a bad thing; I’ve learned from experience that I suck at operator precedence and instead of wasting time looking it up to be sure, hurling a bunch of parenthesis in place not only clarifies my intent, but avoids the problem entirely, I wish more people would do it, as I still run into cases in other people’s code where it takes some time to figure out meaning (usually because these operator precedence obsessed monsters don’t leave comments either ;)

Increasing the precedence won’t help IMO, as it remains just as possible for a user to make a mistake, plus we run the risk of changing the result of currently correct code that works fine with the current precedence but will suddenly give different results if evaluated sooner.

So yeah, I think recommending parenthesis is a good compromise, and good style to encourage when using these operators in more complex cases, not just for avoiding mistakes but also to make the code more readable for others.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

9

I agree, precedence should be left for math operations that are known by
all.

Practically, this is largely the case, in that stdlib operators are more or
less restricted to math operations. Previously, I raised the issue of
bitwise operators and was told that their precedence had been intentionally
rationalized to parallel the more familiar math operations; moreover, Swift
already forces parentheses when bitwise operators are used in combinations
with some other operators that are ambiguous. Other than those, the
operators that are not really related to arithmetic are the range (... and
..<), nil coalescing (??), and ternary (?:) operators. (And assignment
operators, but those are special.)

Since this is not a normal operation, it should be left up to the
developer to tell the computer what to do. The computer should not assume
for you how to handle complex operations next to a nil coalescing operator.

In this case, regarding non-arithmetic operators, all of these are actually
lower precedence than the arithmetic ones. That's a teachable rule, and
also largely holds true for other languages in the C family as well.

···

On Wed, Jun 15, 2016 at 5:35 AM, Jo Albright <me@jo2.co> wrote:

I am intrigued with the idea of explaining to the developer what the order
of their current code will run. Almost like a hint or warning. If there was
a feature in Xcode that explained the order of operations for a given line
of code, this would help the developer choose where to put parenthesis.
But, I don’t believe we should suggest where the parenthesis go (this
becomes another assumption on how they want their code to be). Misaligned
assumptions can frustrate the developer and slow down their coding or
confuse them more.

What does everyone think about adding a visual explanation with the order
of operations in a formula.

Example:

var a = b + c * d / e

Visual Hint (maybe popup like Quick Help or something simpler)

var a = (b + ((c * d) / e))

Or

var x = c * d
var y = x / e
var z = b + y

Some way to quickly represent the order to inform a developer of the
current order.

*I believe there needs to be more communication between the developer and
the computer. An open dialog about what the developer is trying to tell the
computer to do. If the computer says “this is what I think you are telling
me to do”, the developer then can decide if they wrote the correct line of
code.*

Thanks,
Jo

On Jun 15, 2016, at 4:31 AM, Haravikk via swift-evolution < > swift-evolution@swift.org> wrote:

On 15 Jun 2016, at 00:21, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote:
I don't know that it's feasible to warn on every use of operators with
mixed precedence. Doing so would effectively do away with the concept of
precedence at all, since everything would have to be grouped by parentheses
in order to avoid warnings. (The core team has been pretty clear that there
will be no 'optional' warnings, and in certain organizations warnings are
regarded as errors.)

Personally I’m against precedence entirely, as I’m terrible at remembering
the order and even if I could I’d still see myself making tons of mistakes,
as a result I use parenthesis in all but the simplest statements just to be
absolutely clear. The problem with precedence is that while it lets the
compiler choose a logical order to process expressions, you can never be
sure that it’s actually the order the user intended.

Still, I may be in the minority, not sure, maybe other people are happier
with math operator precedence than I am. However, I think that effectively
forcing parenthesis on ?? and ?: may be okay; most of the time these are
used in simple, non-ambiguous cases (either on their own, or with an
assignment), so parenthesis shouldn’t be needed, but anywhere they’re
within larger statements I think it makes sense to encourage parenthesis
use so the compiler can be certain it isn’t guessing at your meaning. I
mean it’s kind of like forcing a defensive coding style, but that’s not
necessarily a bad thing; I’ve learned from experience that I suck at
operator precedence and instead of wasting time looking it up to be sure,
hurling a bunch of parenthesis in place not only clarifies my intent, but
avoids the problem entirely, I wish more people would do it, as I still run
into cases in other people’s code where it takes some time to figure out
meaning (usually because these operator precedence obsessed monsters don’t
leave comments either ;)

Increasing the precedence won’t help IMO, as it remains just as possible
for a user to make a mistake, plus we run the risk of changing the result
of currently correct code that works fine with the current precedence but
will suddenly give different results if evaluated sooner.

So yeah, I think recommending parenthesis is a good compromise, and good
style to encourage when using these operators in more complex cases, not
just for avoiding mistakes but also to make the code more readable for
others.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

1 Like
10

I believe we should not take into account any IDE features when discussing the *language*. One will write Swift script code in vim on linux, other will read in web browser on github etc.
And more, as I understand, in this mailing list we have no opportunity to move any IDE-related idea forward.

Although personally I support requirement of parenthesis for complex cases (because IMO no personal style preferences can justify the very possible bugs/errors in such expressions. if not for the one who wrote the code, then most likely for one who is reading the code), and I do believe such feature will increase the quality of Swift result code and reduce number of possible errors... core team was clear that they will not accept such kind of proposals. The solution they suggest to solve such kind of problems - use lints and other 3rd party source checking tools.

···

On 15.06.2016 13:35, Jo Albright via swift-evolution wrote:

I agree, precedence should be left for math operations that are known by
all. Since this is not a normal operation, it should be left up to the
developer to tell the computer what to do. The computer should not assume
for you how to handle complex operations next to a nil coalescing operator.

I am intrigued with the idea of explaining to the developer what the order
of their current code will run. Almost like a hint or warning. If there was
a feature in Xcode that explained the order of operations for a given line
of code, this would help the developer choose where to put parenthesis.
But, I don’t believe we should suggest where the parenthesis go (this
becomes another assumption on how they want their code to be). Misaligned
assumptions can frustrate the developer and slow down their coding or
confuse them more.

What does everyone think about adding a visual explanation with the order
of operations in a formula.

Example:

var a = b + c * d / e

Visual Hint (maybe popup like Quick Help or something simpler)

var a = (b + ((c * d) / e))

Or

var x = c * d
var y = x / e
var z = b + y

Some way to quickly represent the order to inform a developer of the
current order.

*I believe there needs to be more communication between the developer and
the computer. An open dialog about what the developer is trying to tell the
computer to do. If the computer says “this is what I think you are telling
me to do”, the developer then can decide if they wrote the correct line of
code.*

Thanks,
Jo

On Jun 15, 2016, at 4:31 AM, Haravikk via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On 15 Jun 2016, at 00:21, Xiaodi Wu via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I don't know that it's feasible to warn on every use of operators with
mixed precedence. Doing so would effectively do away with the concept of
precedence at all, since everything would have to be grouped by
parentheses in order to avoid warnings. (The core team has been pretty
clear that there will be no 'optional' warnings, and in certain
organizations warnings are regarded as errors.)

Personally I’m against precedence entirely, as I’m terrible at
remembering the order and even if I could I’d still see myself making
tons of mistakes, as a result I use parenthesis in all but the simplest
statements just to be absolutely clear. The problem with precedence is
that while it lets the compiler choose a logical order to process
expressions, you can never be sure that it’s actually the order the user
intended.

Still, I may be in the minority, not sure, maybe other people are happier
with math operator precedence than I am. However, I think that
effectively forcing parenthesis on ?? and ?: may be okay; most of the
time these are used in simple, non-ambiguous cases (either on their own,
or with an assignment), so parenthesis shouldn’t be needed, but anywhere
they’re within larger statements I think it makes sense to encourage
parenthesis use so the compiler can be certain it isn’t guessing at your
meaning. I mean it’s kind of like forcing a defensive coding style, but
that’s not necessarily a bad thing; I’ve learned from experience that I
suck at operator precedence and instead of wasting time looking it up to
be sure, hurling a bunch of parenthesis in place not only clarifies my
intent, but avoids the problem entirely, I wish more people would do it,
as I still run into cases in other people’s code where it takes some time
to figure out meaning (usually because these operator precedence obsessed
monsters don’t leave comments either ;)

Increasing the precedence won’t help IMO, as it remains just as possible
for a user to make a mistake, plus we run the risk of changing the result
of currently correct code that works fine with the current precedence but
will suddenly give different results if evaluated sooner.

So yeah, I think recommending parenthesis is a good compromise, and good
style to encourage when using these operators in more complex cases, not
just for avoiding mistakes but also to make the code more readable for
others.
_______________________________________________
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

2 Likes
11

+1 for all of your opinions. I also believe that wrong assumption on precedence is a reason of big number of errors. More, I believe precedence in complex expressions can confuse not less than removed ++/-- operators (or requirement to explicit type conversions for different integers types in expression) and it will be Swifty way to prevent this kind of confusion also in the language.

···

On 15.06.2016 11:31, Haravikk via swift-evolution wrote:

On 15 Jun 2016, at 00:21, Xiaodi Wu via swift-evolution
<swift-evolution@swift.org> wrote: I don't know that it's feasible to
warn on every use of operators with mixed precedence. Doing so would
effectively do away with the concept of precedence at all, since
everything would have to be grouped by parentheses in order to avoid
warnings. (The core team has been pretty clear that there will be no
'optional' warnings, and in certain organizations warnings are
regarded as errors.)

Personally I’m against precedence entirely, as I’m terrible at
remembering the order and even if I could I’d still see myself making
tons of mistakes, as a result I use parenthesis in all but the simplest
statements just to be absolutely clear. The problem with precedence is
that while it lets the compiler choose a logical order to process
expressions, you can never be sure that it’s actually the order the user
intended.

Still, I may be in the minority, not sure, maybe other people are
happier with math operator precedence than I am. However, I think that
effectively forcing parenthesis on ?? and ?: may be okay; most of the
time these are used in simple, non-ambiguous cases (either on their own,
or with an assignment), so parenthesis shouldn’t be needed, but anywhere
they’re within larger statements I think it makes sense to encourage
parenthesis use so the compiler can be certain it isn’t guessing at your
meaning. I mean it’s kind of like forcing a defensive coding style, but
that’s not necessarily a bad thing; I’ve learned from experience that I
suck at operator precedence and instead of wasting time looking it up to
be sure, hurling a bunch of parenthesis in place not only clarifies my
intent, but avoids the problem entirely, I wish more people would do it,
as I still run into cases in other people’s code where it takes some
time to figure out meaning (usually because these operator precedence
obsessed monsters don’t leave comments either ;)

Increasing the precedence won’t help IMO, as it remains just as possible
for a user to make a mistake, plus we run the risk of changing the
result of currently correct code that works fine with the current
precedence but will suddenly give different results if evaluated
sooner.

So yeah, I think recommending parenthesis is a good compromise, and good
style to encourage when using these operators in more complex cases, not
just for avoiding mistakes but also to make the code more readable for
others. _______________________________________________ swift-evolution
mailing list swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

12

Unrelated to anything else in this discussion, I just wanted to respond to this and say that I’m totally opposed to this line of thinking. If we continue to design languages that must accommodate the lowest common denominator in terms of tooling, we’ll never advance anything in meaningful ways. Tooling is super important and it is mostly terrible. It could be so much better. We don’t have much (any?) influence over Xcode via swift-evolution, but if the language evolves in ways where smarter, better, more advanced IDEs are the best way to use it, then Xcode will adapt and if Xcode adapts and proves a better workflow, then other tools will also adapt and everyone in any language on all platforms will eventually benefit from that exploration.

l8r
Sean

···

On Jun 15, 2016, at 7:21 AM, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:

I believe we should not take into account any IDE features when discussing the *language*. One will write Swift script code in vim on linux, other will read in web browser on github etc.

1 Like
13

>
> I believe we should not take into account any IDE features when
discussing the *language*. One will write Swift script code in vim on
linux, other will read in web browser on github etc.

Unrelated to anything else in this discussion, I just wanted to respond to
this and say that I’m totally opposed to this line of thinking. If we
continue to design languages that must accommodate the lowest common
denominator in terms of tooling, we’ll never advance anything in meaningful
ways. Tooling is super important and it is mostly terrible. It could be so
much better.

I believe the core team has pointed out in the past that in fact decisions
here *should* acknowledge the existence of the whole ecosystem of tools.

We don’t have much (any?) influence over Xcode via swift-evolution,

Actually, IIUC, anything in the Swift open source project is fair game
here, and SourceKit (which supports IDE features for Swift) is indeed part
of the open source project.

···

On Wed, Jun 15, 2016 at 9:19 AM, Sean Heber via swift-evolution < swift-evolution@swift.org> wrote:

> On Jun 15, 2016, at 7:21 AM, Vladimir.S via swift-evolution < > swift-evolution@swift.org> wrote:

but if the language evolves in ways where smarter, better, more advanced
IDEs are the best way to use it, then Xcode will adapt and if Xcode adapts
and proves a better workflow, then other tools will also adapt and everyone
in any language on all platforms will eventually benefit from that
exploration.

l8r
Sean

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

14

I believe we should not take into account any IDE features when
discussing the *language*. One will write Swift script code in vim on
linux, other will read in web browser on github etc.

Unrelated to anything else in this discussion, I just wanted to respond
to this and say that I’m totally opposed to this line of thinking. If we
continue to design languages that must accommodate the lowest common
denominator in terms of tooling, we’ll never advance anything in
meaningful ways. Tooling is super important and it is mostly terrible.
It could be so much better. We don’t have much (any?) influence over
Xcode via swift-evolution, but if the language evolves in ways where
smarter, better, more advanced IDEs are the best way to use it, then
Xcode will adapt and if Xcode adapts and proves a better workflow, then
other tools will also adapt and everyone in any language on all
platforms will eventually benefit from that exploration.

Well, of course I support improvement of tools & IDEs in all the ways that can help developer. But I'm against suggestions to solve some problem *in languge* by introducing some feature in *IDE*(especially in only one IDE - XCode), like the suggestion to solve ambiguity with order of processing in complex expression by *only* showing some hints in XCode.
I.e. I'm voting to solve problem in language itself first, and then(or if can't be solved) in IDE.

···

On 15.06.2016 17:19, Sean Heber wrote:

On Jun 15, 2016, at 7:21 AM, Vladimir.S via swift-evolution >> <swift-evolution@swift.org> wrote:

l8r Sean

15

I believe we should not take into account any IDE features when
discussing the *language*. One will write Swift script code in vim on
linux, other will read in web browser on github etc.

Unrelated to anything else in this discussion, I just wanted to respond
to this and say that I’m totally opposed to this line of thinking. If we
continue to design languages that must accommodate the lowest common
denominator in terms of tooling, we’ll never advance anything in
meaningful ways. Tooling is super important and it is mostly terrible.
It could be so much better. We don’t have much (any?) influence over
Xcode via swift-evolution, but if the language evolves in ways where
smarter, better, more advanced IDEs are the best way to use it, then
Xcode will adapt and if Xcode adapts and proves a better workflow, then
other tools will also adapt and everyone in any language on all
platforms will eventually benefit from that exploration.

Well, of course I support improvement of tools & IDEs in all the ways that
can help developer. But I'm against suggestions to solve some problem *in
languge* by introducing some feature in *IDE*(especially in only one IDE -
XCode), like the suggestion to solve ambiguity with order of processing in
complex expression by *only* showing some hints in XCode.
I.e. I'm voting to solve problem in language itself first, and then(or if
can't be solved) in IDE.

I think the counterpoint to be made here is that if a satisfying solution
to the problem can be found through better tooling, then arguably the
problem lies with tooling and not with the language itself.

···

On Wed, Jun 15, 2016 at 10:51 AM, Vladimir.S via swift-evolution < swift-evolution@swift.org> wrote:

On 15.06.2016 17:19, Sean Heber wrote:

On Jun 15, 2016, at 7:21 AM, Vladimir.S via swift-evolution >>> <swift-evolution@swift.org> wrote:

l8r Sean

_______________________________________________

swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

16

            I believe we should not take into account any IDE features when
            discussing the *language*. One will write Swift script code in
            vim on
            linux, other will read in web browser on github etc.

        Unrelated to anything else in this discussion, I just wanted to respond
        to this and say that I’m totally opposed to this line of thinking.
        If we
        continue to design languages that must accommodate the lowest common
        denominator in terms of tooling, we’ll never advance anything in
        meaningful ways. Tooling is super important and it is mostly terrible.
        It could be so much better. We don’t have much (any?) influence over
        Xcode via swift-evolution, but if the language evolves in ways where
        smarter, better, more advanced IDEs are the best way to use it, then
        Xcode will adapt and if Xcode adapts and proves a better workflow, then
        other tools will also adapt and everyone in any language on all
        platforms will eventually benefit from that exploration.

    Well, of course I support improvement of tools & IDEs in all the ways
    that can help developer. But I'm against suggestions to solve some
    problem *in languge* by introducing some feature in *IDE*(especially in
    only one IDE - XCode), like the suggestion to solve ambiguity with
    order of processing in complex expression by *only* showing some hints
    in XCode.
    I.e. I'm voting to solve problem in language itself first, and then(or
    if can't be solved) in IDE.

I think the counterpoint to be made here is that if a satisfying solution
to the problem can be found through better tooling, then arguably the
problem lies with tooling and not with the language itself.

Yes, probably. But I do believe the language itself is a first class citizen, tools are just helpers. You need to have the same coding features on any platform/editor/IDE where you write Swift code. You should not be able to easily write complex expressions just because of super-smart helper in XCode but be without help on Linux platform. Tool can exist for example only for XCode but absent for other platform you are coding on also. IMO You just can't depend on tools in the question of language features. This is my strong opinion.

···

On 15.06.2016 19:00, Xiaodi Wu wrote:

On Wed, Jun 15, 2016 at 10:51 AM, Vladimir.S via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
    On 15.06.2016 17:19, Sean Heber wrote:
            On Jun 15, 2016, at 7:21 AM, Vladimir.S via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> > wrote:

        l8r Sean

    _______________________________________________
    swift-evolution mailing list
    swift-evolution@swift.org <mailto:swift-evolution@swift.org>
    https://lists.swift.org/mailman/listinfo/swift-evolution

17

Here's a reason why the language should not depend on or require features of an IDE: they don't work. Xcode, five years after this topic, is terrible about code completion. Your code can't have errors in it, or it won't work. And it's while you're mid-expression that you need it the most.

2 Likes