Reconsider ++ and -- operators removal and prevent other well-known operators from change

[vmartinelli (Vanderlei Martinelli)]

Hello everybody.

I see Swift as a member of “C family" (a granddaughter/grandson of C, a
daughter/son of Objective-C). OK, she/he is different and has her/his own
personality like a daughter/son should be and have, but I still like to see
Swift and recognize some traces that I know are things that became from C.

This said, I would like to say that after the removal of `++` and `--` my
code becomes less readable and more prone to errors. There were two
characters to differentiate an addition from a subtraction, now there is
only one (`+= 1`, `-= 1`). Also the character keys are very close in the US
keyboard so it is easier to make a mistake and is not as simple as the
previous solution when I typed two times the same key. Using Erica's way of
saying certain things: I do not love the removal of `++` and `--`.

I do not know how far the Swift is to the adolescence, but it is certain
that teenagers are rebels. There's something very good at it. In most cases
they are to be certain. But in some things they regret later. Now I see
that many of us want to replace the `??` operator to something else. I'm
wondering the next steps... To replace the `&&`, `||` and `!` operator
with `and`, `or`, `not`? I’m not "loving" this as well.

Are these changes really necessary for the Swift evolution? Is it the
better path to deny its origin and to try to fix what is not broken? I
would like you to think about it.

There are many other things that really need to be improved and repaired
and other things needed to are created. Those mentioned here in this
message does not seem to fit it.

Regards,

-Van

[Austin (Austin Zheng)]

Strong -1 to this proposal.

If your code is in dire need of ++/--, you can always define them yourself using the language affordances. (Unlike, say, defining your own C-style for loop.)

Other than that, ++/-- were a crufty legacy carryover from C, and their disadvantages are adequately described in the rationale portion of the proposal.

?? and ?: are in no imminent danger, and even if they were their removal should be debated on the merits of those specific operators.

Finally, if people are going to try and re-open the pre-SE-0005 proposals for retroactive discussion, maybe we should have a 'community comments' period for each of them and just get it over with.

Austin

···

On Jan 30, 2016, at 10:12 AM, Vanderlei Martinelli via swift-evolution <swift-evolution@swift.org> wrote:

Hello everybody.

I see Swift as a member of “C family" (a granddaughter/grandson of C, a daughter/son of Objective-C). OK, she/he is different and has her/his own personality like a daughter/son should be and have, but I still like to see Swift and recognize some traces that I know are things that became from C.

This said, I would like to say that after the removal of `++` and `--` my code becomes less readable and more prone to errors. There were two characters to differentiate an addition from a subtraction, now there is only one (`+= 1`, `-= 1`). Also the character keys are very close in the US keyboard so it is easier to make a mistake and is not as simple as the previous solution when I typed two times the same key. Using Erica's way of saying certain things: I do not love the removal of `++` and `--`.

I do not know how far the Swift is to the adolescence, but it is certain that teenagers are rebels. There's something very good at it. In most cases they are to be certain. But in some things they regret later. Now I see that many of us want to replace the `??` operator to something else. I'm wondering the next steps... To replace the `&&`, `||` and `!` operator with `and`, `or`, `not`? I’m not "loving" this as well.

Are these changes really necessary for the Swift evolution? Is it the better path to deny its origin and to try to fix what is not broken? I would like you to think about it.

There are many other things that really need to be improved and repaired and other things needed to are created. Those mentioned here in this message does not seem to fit it.

Regards,

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

[David_Sweeris]

My understanding is that while we’re not specifically avoiding “similarity with C”, it’s not one of Swift’s design goals, either. That it’s happened in some areas is really just a side-effect of, a) Swift has to be able to interoperate with C (and Obj-C) code, and b) sometimes there’s nothing wrong with C’s syntax.

I’m “+0.25” towards removing ++ / —. I liked some of the clever code they enabled, but I understand (and agree with) the reasons for their removal. If you want to keep using them, though, they’re trivially easy to put back in:
prefix operator ++ {}
postfix operator ++ {}
prefix func ++ <T: protocol<IntegerArithmeticType, IntegerLiteralConvertible>> (inout x: T) -> T {
    x += 1
    return x
}
postfix func ++ <T: protocol<IntegerArithmeticType, IntegerLiteralConvertible>> (inout x: T) -> T {
    defer { x += 1 }
    return x
}

var i = 0
print(i++) // 0
print(i) // 1
print(++i) // 2
print(i) // 2

And if you really prefer C’s behavior, you could even make them silently overflow instead of crashing (just beware the infinite loops…):
prefix func ++ <T: protocol<IntegerArithmeticType, IntegerLiteralConvertible>> (inout x: T) -> T {
    x = x &+ 1
    return x
}
postfix func ++ <T: protocol<IntegerArithmeticType, IntegerLiteralConvertible>> (inout x: T) -> T {
    defer { x = x &+ 1 }
    return x
}
var i:UInt8 = 255
print(i++) // 255
print(i) // 0

- Dave Sweeris (The Other Dave)

···

On Jan 30, 2016, at 10:12, Vanderlei Martinelli via swift-evolution <swift-evolution@swift.org> wrote:

Hello everybody.

I see Swift as a member of “C family" (a granddaughter/grandson of C, a daughter/son of Objective-C). OK, she/he is different and has her/his own personality like a daughter/son should be and have, but I still like to see Swift and recognize some traces that I know are things that became from C.

This said, I would like to say that after the removal of `++` and `--` my code becomes less readable and more prone to errors. There were two characters to differentiate an addition from a subtraction, now there is only one (`+= 1`, `-= 1`). Also the character keys are very close in the US keyboard so it is easier to make a mistake and is not as simple as the previous solution when I typed two times the same key. Using Erica's way of saying certain things: I do not love the removal of `++` and `--`.

I do not know how far the Swift is to the adolescence, but it is certain that teenagers are rebels. There's something very good at it. In most cases they are to be certain. But in some things they regret later. Now I see that many of us want to replace the `??` operator to something else. I'm wondering the next steps... To replace the `&&`, `||` and `!` operator with `and`, `or`, `not`? I’m not "loving" this as well.

Are these changes really necessary for the Swift evolution? Is it the better path to deny its origin and to try to fix what is not broken? I would like you to think about it.

There are many other things that really need to be improved and repaired and other things needed to are created. Those mentioned here in this message does not seem to fit it.

Regards,

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

[willstanton]

Hello,

I think Van made good points about readability, and I do not recall the retention of ‘++’ and ‘--’ being discussed much (perhaps since SE-0004 and 0007 were accepted). So in case it’s up for discussion:

At first, I really disliked the removal of ++ and --. In my opinion, the first three disadvantages in SE-0004 (https://github.com/apple/swift-evolution/blob/master/proposals/0004-remove-pre-post-inc-decrement.md\) were not that strong:

These operators increase the burden to learn Swift as a first programming language - or any other case where you don't already know these operators from a different language.

‘++’ does not seem less obvious than ‘+=’ and learning about the 2-4 extra operators doesn’t seem burdensome.
++ and -- are also not particularly rare (I remember being surprised that Python did not support them)

Their expressive advantage is minimal - x++ is not much shorter than x += 1.

Still, `++` is easier to type than `+= 1`

Swift already deviates from C in that the =, += and other assignment-like operations returns Void (for a number of reasons). These operators are inconsistent with that model.

I liked the alternative considered: keep ++ and -- while returning void

But I became less bothered by the proposal, since I agreed with this:

Swift has powerful features that eliminate many of the common reasons you'd use ++i in a C-style for loop in other languages, so these are relatively infrequently used in well-written Swift code. These features include the for-in loop, ranges, enumerate, map, etc.

So, I respectfully disagree with removing the operators, but I also don’t have strong objections (as I first thought I might).

Regards,
Will Stanton

···

On Jan 30, 2016, at 1:12 PM, Vanderlei Martinelli via swift-evolution <swift-evolution@swift.org> wrote:

Hello everybody.

I see Swift as a member of “C family" (a granddaughter/grandson of C, a daughter/son of Objective-C). OK, she/he is different and has her/his own personality like a daughter/son should be and have, but I still like to see Swift and recognize some traces that I know are things that became from C.

This said, I would like to say that after the removal of `++` and `--` my code becomes less readable and more prone to errors. There were two characters to differentiate an addition from a subtraction, now there is only one (`+= 1`, `-= 1`). Also the character keys are very close in the US keyboard so it is easier to make a mistake and is not as simple as the previous solution when I typed two times the same key. Using Erica's way of saying certain things: I do not love the removal of `++` and `--`.

I do not know how far the Swift is to the adolescence, but it is certain that teenagers are rebels. There's something very good at it. In most cases they are to be certain. But in some things they regret later. Now I see that many of us want to replace the `??` operator to something else. I'm wondering the next steps... To replace the `&&`, `||` and `!` operator with `and`, `or`, `not`? I’m not "loving" this as well.

Are these changes really necessary for the Swift evolution? Is it the better path to deny its origin and to try to fix what is not broken? I would like you to think about it.

There are many other things that really need to be improved and repaired and other things needed to are created. Those mentioned here in this message does not seem to fit it.

Regards,

-Van

[vmartinelli (Vanderlei Martinelli)]

Oops: *needed to *be* created

···

On Sat, Jan 30, 2016 at 4:12 PM, Vanderlei Martinelli < vmartinelli@alecrim.com> wrote:

Hello everybody.

I see Swift as a member of “C family" (a granddaughter/grandson of C, a
daughter/son of Objective-C). OK, she/he is different and has her/his own
personality like a daughter/son should be and have, but I still like to see
Swift and recognize some traces that I know are things that became from C.

This said, I would like to say that after the removal of `++` and `--` my
code becomes less readable and more prone to errors. There were two
characters to differentiate an addition from a subtraction, now there is
only one (`+= 1`, `-= 1`). Also the character keys are very close in the US
keyboard so it is easier to make a mistake and is not as simple as the
previous solution when I typed two times the same key. Using Erica's way of
saying certain things: I do not love the removal of `++` and `--`.

I do not know how far the Swift is to the adolescence, but it is certain
that teenagers are rebels. There's something very good at it. In most cases
they are to be certain. But in some things they regret later. Now I see
that many of us want to replace the `??` operator to something else. I'm
wondering the next steps... To replace the `&&`, `||` and `!` operator
with `and`, `or`, `not`? I’m not "loving" this as well.

Are these changes really necessary for the Swift evolution? Is it the
better path to deny its origin and to try to fix what is not broken? I
would like you to think about it.

There are many other things that really need to be improved and repaired
and other things needed to are created. Those mentioned here in this
message does not seem to fit it.

Regards,

-Van

[vmartinelli (Vanderlei Martinelli)]

Hello. I also like the alternative: keep ++ and -- while returning void. :-)

···

On Sat, Jan 30, 2016 at 5:00 PM, Will Stanton <willstanton1@yahoo.com> wrote:

Hello Van,

I think you make some good points about readability, and I do not recall
the retention of ‘++’ and ‘--' being discussed much, perhaps since SE-0004
and 0007 were accepted. All the same:

At first, I really disliked the removal of ++ and --. In my opinion, the
first three disadvantages in SE-0004 (
https://github.com/apple/swift-evolution/blob/master/proposals/0004-remove-pre-post-inc-decrement.md\)
were not that strong:

> These operators increase the burden to learn Swift as a first
programming language - or any other case where you don't already know these
operators from a different language.

‘++’ does not seem less obvious than ‘+=’ and learning about the 2-4
extra operators doesn’t seem burdensome.
++ and -- are also not particularly rare (I remember being surprised that
Python did not support them)

> Their expressive advantage is minimal - x++ is not much shorter than x
+= 1.
Still, `++` is easier to type than `+= 1`

> Swift already deviates from C in that the =, += and other
assignment-like operations returns Void (for a number of reasons). These
operators are inconsistent with that model.

I liked the alternative considered: keep ++ and -- while returning void

But over a few days I became less bothered by the proposal. I agreed with
this:
> Swift has powerful features that eliminate many of the common reasons
you'd use ++i in a C-style for loop in other languages, so these are
relatively infrequently used in well-written Swift code. These features
include the for-in loop, ranges, enumerate, map, etc.

I respectfully disagree with removing the operators but also don’t have
strong objections.

Regards,
Will Stanton

> On Jan 30, 2016, at 1:12 PM, Vanderlei Martinelli via swift-evolution < > swift-evolution@swift.org> wrote:
>
> Hello everybody.
>
> I see Swift as a member of “C family" (a granddaughter/grandson of C, a
daughter/son of Objective-C). OK, she/he is different and has her/his own
personality like a daughter/son should be and have, but I still like to see
Swift and recognize some traces that I know are things that became from C.
>
> This said, I would like to say that after the removal of `++` and `--`
my code becomes less readable and more prone to errors. There were two
characters to differentiate an addition from a subtraction, now there is
only one (`+= 1`, `-= 1`). Also the character keys are very close in the US
keyboard so it is easier to make a mistake and is not as simple as the
previous solution when I typed two times the same key. Using Erica's way of
saying certain things: I do not love the removal of `++` and `--`.

[vmartinelli (Vanderlei Martinelli)]

Strong -1 to people being so obtuse with other people discussing things in
a discussion group. ;-)

OK. I got your point. A “community comments” period may be a good
ideia, since "community" will not be used as a term to segregate those who
not have truly a say.

Regards,
-- Vanderlei Martinelli

···

On Sat, Jan 30, 2016 at 5:31 PM, Austin Zheng <austinzheng@gmail.com> wrote:

Strong -1 to this proposal.

If your code is in dire need of ++/--, you can always define them yourself
using the language affordances. (Unlike, say, defining your own C-style for
loop.)

Other than that, ++/-- were a crufty legacy carryover from C, and their
disadvantages are adequately described in the rationale portion of the
proposal.

?? and ?: are in no imminent danger, and even if they were their removal
should be debated on the merits of those specific operators.

Finally, if people are going to try and re-open the pre-SE-0005 proposals
for retroactive discussion, maybe we should have a 'community comments'
period for each of them and just get it over with.

Austin

On Jan 30, 2016, at 10:12 AM, Vanderlei Martinelli via swift-evolution < > swift-evolution@swift.org> wrote:

Hello everybody.

I see Swift as a member of “C family" (a granddaughter/grandson of C, a
daughter/son of Objective-C). OK, she/he is different and has her/his own
personality like a daughter/son should be and have, but I still like to see
Swift and recognize some traces that I know are things that became from C.

This said, I would like to say that after the removal of `++` and `--` my
code becomes less readable and more prone to errors. There were two
characters to differentiate an addition from a subtraction, now there is
only one (`+= 1`, `-= 1`). Also the character keys are very close in the US
keyboard so it is easier to make a mistake and is not as simple as the
previous solution when I typed two times the same key. Using Erica's way of
saying certain things: I do not love the removal of `++` and `--`.

I do not know how far the Swift is to the adolescence, but it is certain
that teenagers are rebels. There's something very good at it. In most cases
they are to be certain. But in some things they regret later. Now I see
that many of us want to replace the `??` operator to something else. I'm
wondering the next steps... To replace the `&&`, `||` and `!` operator
with `and`, `or`, `not`? I’m not "loving" this as well.

Are these changes really necessary for the Swift evolution? Is it the
better path to deny its origin and to try to fix what is not broken? I
would like you to think about it.

There are many other things that really need to be improved and repaired
and other things needed to are created. Those mentioned here in this
message does not seem to fit it.

Regards,

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

[codafi (Robert Widmann)]

Strong -1.

The readability arguments for ++ and — make no sense to me given that it is much more obvious, refactorable, and declarative to use

x = x.successor()

and

x = x.predecessor()

in their place. ++ and -- outside of loops are a code smell, and even within loops can easily be mistaken for one another or misused. As others have no doubt pointed out, if you want them back then define the operators yourself. Otherwise, I can’t say I’ve mourned the loss of these things enough to consider their reintroduction.

~Robert Widmann

···

On Jan 30, 2016, at 1:12 PM, Vanderlei Martinelli via swift-evolution <swift-evolution@swift.org> wrote:

Hello everybody.

I see Swift as a member of “C family" (a granddaughter/grandson of C, a daughter/son of Objective-C). OK, she/he is different and has her/his own personality like a daughter/son should be and have, but I still like to see Swift and recognize some traces that I know are things that became from C.

This said, I would like to say that after the removal of `++` and `--` my code becomes less readable and more prone to errors. There were two characters to differentiate an addition from a subtraction, now there is only one (`+= 1`, `-= 1`). Also the character keys are very close in the US keyboard so it is easier to make a mistake and is not as simple as the previous solution when I typed two times the same key. Using Erica's way of saying certain things: I do not love the removal of `++` and `--`.

I do not know how far the Swift is to the adolescence, but it is certain that teenagers are rebels. There's something very good at it. In most cases they are to be certain. But in some things they regret later. Now I see that many of us want to replace the `??` operator to something else. I'm wondering the next steps... To replace the `&&`, `||` and `!` operator with `and`, `or`, `not`? I’m not "loving" this as well.

Are these changes really necessary for the Swift evolution? Is it the better path to deny its origin and to try to fix what is not broken? I would like you to think about it.

There are many other things that really need to be improved and repaired and other things needed to are created. Those mentioned here in this message does not seem to fit it.

Regards,

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

[Radek_Pietruszewski]

Vanderlei,

The ++/— operators weren’t removed just because they are redundant with `+= 1`.

++ is a bit special in that it doesn’t just modify the receiver, it also returns the modified variable. What’s more, there’s this subtle difference between `++foo` and `foo++` when you pass it further along. And that, that difference, makes such use dangerous, and prone to bugs.

It’s also a useful feature — if you live in the world of C. But in Swift, where explicit increments and decrements are far less common, it was deemed that the slight utility and convenience of it does not justify the cost of potential confusion and bugs that arise from that.

Give the actual proposal a read: https://github.com/apple/swift-evolution/blob/master/proposals/0004-remove-pre-post-inc-decrement.md — it does a pretty good job at explaining the disadvantages of ++ and —. It’s not just a stylistic choice.

And &&, ||, !, are not in danger. Browse this mailing list’s history — it’s been proposed more than once and immediately rejected as a change that really isn’t justified in any way.

Also, let me quote Doug Gregor from the core team:

We certainly don’t want open-ended rehashing of past decisions, and I’d like to have the baseline rule be something very close to “the core team’s decisions are final” both to prevent such rehashing and also to emphasize the seriousness of the public review process: the public review is the point at which we need to gather widespread feedback on the direction of the language. Determining that there is a problem “after we shipped it” is a failure of the evolution process.

The evolution process has a number of stages (idea/proposal draft/public review/core team), where each new stage brings additional scrutiny of the proposal. The hope is that this scrutiny is enough to prevent us from making poor decisions that may need to be overturned, and that the swift-evolution community is representative enough of the larger Swift community to provide that scrutiny. SE-0003 is somewhat special because it’s one of a few changes for Swift 3 that were decided prior to open-sourcing Swift: it didn’t go through the whole evolution process, so it didn’t have as many eyes on it as language changes do now.

So, overall, I’d say that the core team’s decisions should be considered effectively final. If something gets through the entire evolution process and then we later find out it was a bad decision—e.g., due to massive negative feedback when it reaches the wider Swift community or unforeseen difficulties in implementation/rollout/etc.—the core team could bring up the idea of backing out the change. However, the evolution process *should* prevent this.

Best,
— Radek

···

On 30 Jan 2016, at 19:12, Vanderlei Martinelli via swift-evolution <swift-evolution@swift.org> wrote:

Hello everybody.

I see Swift as a member of “C family" (a granddaughter/grandson of C, a daughter/son of Objective-C). OK, she/he is different and has her/his own personality like a daughter/son should be and have, but I still like to see Swift and recognize some traces that I know are things that became from C.

This said, I would like to say that after the removal of `++` and `--` my code becomes less readable and more prone to errors. There were two characters to differentiate an addition from a subtraction, now there is only one (`+= 1`, `-= 1`). Also the character keys are very close in the US keyboard so it is easier to make a mistake and is not as simple as the previous solution when I typed two times the same key. Using Erica's way of saying certain things: I do not love the removal of `++` and `--`.

I do not know how far the Swift is to the adolescence, but it is certain that teenagers are rebels. There's something very good at it. In most cases they are to be certain. But in some things they regret later. Now I see that many of us want to replace the `??` operator to something else. I'm wondering the next steps... To replace the `&&`, `||` and `!` operator with `and`, `or`, `not`? I’m not "loving" this as well.

Are these changes really necessary for the Swift evolution? Is it the better path to deny its origin and to try to fix what is not broken? I would like you to think about it.

There are many other things that really need to be improved and repaired and other things needed to are created. Those mentioned here in this message does not seem to fit it.

Regards,

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

[Tino]

I do not know how far the Swift is to the adolescence, but it is certain that teenagers are rebels. There's something very good at it. In most cases they are to be certain. But in some things they regret later.

Children have to learn their own lessons — and I guess re-adding "++" wouldn't be as complicated as a big tattoo on your neck ;-)

My first thought on the removal was "we'll see many custom post-increment operators soon", and that may be true; but in the meantime, I came to the conclusion that I won't define those custom operators, but rather configure my system to replace "++" with " += 1":
Typing the old operator is definitely faster, but I don't mind if it's turned into something else automatically (when there is no performance gain for pre-increment, I've always preferred the post-variants).

Tino

[Austin (Austin Zheng)]

I think a "community comments" period for each review is a perfectly fine idea :).

Doug Gregor's comments quoted below clearly state that accepted proposals are meant to be final, precisely in order to avoid unending back-and-forth counterproposals to things that people can never agree upon. However, there's a good argument that the first proposals should be re-opened up for community discussion, because they didn't go through the formal process.

Regarding "truly having a say": Swift is not designed by referendum; the core team takes community feedback into account but is not bound by it when making decisions re. the language. In every proposal rejection or acceptance so far popularity (or lack thereof) has only been one of the stated factors.

Best,
Austin

···

On Jan 30, 2016, at 11:41 AM, Vanderlei Martinelli <vmartinelli@alecrim.com> wrote:

Strong -1 to people being so obtuse with other people discussing things in a discussion group. ;-)

OK. I got your point. A “community comments” period may be a good ideia, since "community" will not be used as a term to segregate those who not have truly a say.

Regards,
-- Vanderlei Martinelli

On Sat, Jan 30, 2016 at 5:31 PM, Austin Zheng <austinzheng@gmail.com <mailto:austinzheng@gmail.com>> wrote:
Strong -1 to this proposal.

If your code is in dire need of ++/--, you can always define them yourself using the language affordances. (Unlike, say, defining your own C-style for loop.)

Other than that, ++/-- were a crufty legacy carryover from C, and their disadvantages are adequately described in the rationale portion of the proposal.

?? and ?: are in no imminent danger, and even if they were their removal should be debated on the merits of those specific operators.

Finally, if people are going to try and re-open the pre-SE-0005 proposals for retroactive discussion, maybe we should have a 'community comments' period for each of them and just get it over with.

Austin

On Jan 30, 2016, at 10:12 AM, Vanderlei Martinelli via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hello everybody.

I see Swift as a member of “C family" (a granddaughter/grandson of C, a daughter/son of Objective-C). OK, she/he is different and has her/his own personality like a daughter/son should be and have, but I still like to see Swift and recognize some traces that I know are things that became from C.

This said, I would like to say that after the removal of `++` and `--` my code becomes less readable and more prone to errors. There were two characters to differentiate an addition from a subtraction, now there is only one (`+= 1`, `-= 1`). Also the character keys are very close in the US keyboard so it is easier to make a mistake and is not as simple as the previous solution when I typed two times the same key. Using Erica's way of saying certain things: I do not love the removal of `++` and `--`.

I do not know how far the Swift is to the adolescence, but it is certain that teenagers are rebels. There's something very good at it. In most cases they are to be certain. But in some things they regret later. Now I see that many of us want to replace the `??` operator to something else. I'm wondering the next steps... To replace the `&&`, `||` and `!` operator with `and`, `or`, `not`? I’m not "loving" this as well.

Are these changes really necessary for the Swift evolution? Is it the better path to deny its origin and to try to fix what is not broken? I would like you to think about it.

There are many other things that really need to be improved and repaired and other things needed to are created. Those mentioned here in this message does not seem to fit it.

Regards,

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

[Chris_Lattner]

Hello. I also like the alternative: keep ++ and -- while returning void. :-)

Vanderlei, please read the proposal in question. This alternative is directly addressed at the end.

-Chris

···

On Jan 30, 2016, at 11:13 AM, Vanderlei Martinelli via swift-evolution <swift-evolution@swift.org> wrote:

On Sat, Jan 30, 2016 at 5:00 PM, Will Stanton <willstanton1@yahoo.com <mailto:willstanton1@yahoo.com>> wrote:
Hello Van,

I think you make some good points about readability, and I do not recall the retention of ‘++’ and ‘--' being discussed much, perhaps since SE-0004 and 0007 were accepted. All the same:

At first, I really disliked the removal of ++ and --. In my opinion, the first three disadvantages in SE-0004 (https://github.com/apple/swift-evolution/blob/master/proposals/0004-remove-pre-post-inc-decrement.md\) were not that strong:

> These operators increase the burden to learn Swift as a first programming language - or any other case where you don't already know these operators from a different language.

‘++’ does not seem less obvious than ‘+=’ and learning about the 2-4 extra operators doesn’t seem burdensome.
++ and -- are also not particularly rare (I remember being surprised that Python did not support them)

> Their expressive advantage is minimal - x++ is not much shorter than x += 1.
Still, `++` is easier to type than `+= 1`

> Swift already deviates from C in that the =, += and other assignment-like operations returns Void (for a number of reasons). These operators are inconsistent with that model.

I liked the alternative considered: keep ++ and -- while returning void

But over a few days I became less bothered by the proposal. I agreed with this:
> Swift has powerful features that eliminate many of the common reasons you'd use ++i in a C-style for loop in other languages, so these are relatively infrequently used in well-written Swift code. These features include the for-in loop, ranges, enumerate, map, etc.

I respectfully disagree with removing the operators but also don’t have strong objections.

Regards,
Will Stanton

> On Jan 30, 2016, at 1:12 PM, Vanderlei Martinelli via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
> Hello everybody.
>
> I see Swift as a member of “C family" (a granddaughter/grandson of C, a daughter/son of Objective-C). OK, she/he is different and has her/his own personality like a daughter/son should be and have, but I still like to see Swift and recognize some traces that I know are things that became from C.
>
> This said, I would like to say that after the removal of `++` and `--` my code becomes less readable and more prone to errors. There were two characters to differentiate an addition from a subtraction, now there is only one (`+= 1`, `-= 1`). Also the character keys are very close in the US keyboard so it is easier to make a mistake and is not as simple as the previous solution when I typed two times the same key. Using Erica's way of saying certain things: I do not love the removal of `++` and `--`.

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

[vmartinelli (Vanderlei Martinelli)]

Radek, thank you for bringing this up, but I know the reasons they have
been removed and I read the older messages (the `&&`, `||` and `!`
operators mention was an intended hyperbole). I am aware of the “Swift
evolution process".

And I still do not agree with the removal. You can consider code like:

network.activiy++
doSomeNetworkActiviy()
network.activiy--

`activity` here does not need to be a numeric variable, but other thing.
Does not make sense to write...

network.activiy += 1
doSomeNetworkActiviy()
network.activiy -= 1

...since I cannot add or subtract more than 1 in any case.

Now we can use methods like `increment` or `decrement`, but the two words,
when reading, are similar and not clear as `++` and `--`.

OK, but my initial message intent is to prevent operator like `?:`, `??`
and others to go away too (and maybe bring back the `++` and `--`
operators, who knows?).

Best,
-Van

···

On Sat, Jan 30, 2016 at 5:05 PM, Radosław Pietruszewski <radexpl@gmail.com> wrote:

Vanderlei,

The ++/— operators weren’t removed just because they are redundant with
`+= 1`.

++ is a bit special in that it doesn’t just modify the receiver, it also
returns the modified variable. What’s more, there’s this subtle difference
between `++foo` and `foo++` when you pass it further along. And that, that
difference, makes such use dangerous, and prone to bugs.

It’s also a useful feature — if you live in the world of C. But in Swift,
where explicit increments and decrements are far less common, it was deemed
that the slight utility and convenience of it does not justify the cost of
potential confusion and bugs that arise from that.

Give the actual proposal a read:
https://github.com/apple/swift-evolution/blob/master/proposals/0004-remove-pre-post-inc-decrement.md —
it does a pretty good job at explaining the disadvantages of ++ and —. It’s
not just a stylistic choice.

And &&, ||, !, are not in danger. Browse this mailing list’s history —
it’s been proposed more than once and immediately rejected as a change that
really isn’t justified in any way.

Also, let me quote Doug Gregor from the core team:

We certainly don’t want open-ended rehashing of past decisions, and I’d
like to have the baseline rule be something very close to “the core team’s
decisions are final” both to prevent such rehashing and also to emphasize
the seriousness of the public review process: the public review *is* the
point at which we need to gather widespread feedback on the direction of
the language. Determining that there is a problem “after we shipped it” is
a failure of the evolution process.

The evolution process has a number of stages (idea/proposal draft/public
review/core team), where each new stage brings additional scrutiny of the
proposal. The hope is that this scrutiny is enough to prevent us from
making poor decisions that may need to be overturned, and that the
swift-evolution community is representative enough of the larger Swift
community to provide that scrutiny. SE-0003 is somewhat special because
it’s one of a few changes for Swift 3 that were decided prior to
open-sourcing Swift: it didn’t go through the whole evolution process, so
it didn’t have as many eyes on it as language changes do now.

So, overall, I’d say that the core team’s decisions should be considered
effectively final. If something gets through the entire evolution process
and then we later find out it was a bad decision—e.g., due to massive
negative feedback when it reaches the wider Swift community or unforeseen
difficulties in implementation/rollout/etc.—the core team could bring up
the idea of backing out the change. However, the evolution process *should*
prevent this.

Best,
— Radek

On 30 Jan 2016, at 19:12, Vanderlei Martinelli via swift-evolution < > swift-evolution@swift.org> wrote:

Hello everybody.

I see Swift as a member of “C family" (a granddaughter/grandson of C, a
daughter/son of Objective-C). OK, she/he is different and has her/his own
personality like a daughter/son should be and have, but I still like to see
Swift and recognize some traces that I know are things that became from C.

This said, I would like to say that after the removal of `++` and `--` my
code becomes less readable and more prone to errors. There were two
characters to differentiate an addition from a subtraction, now there is
only one (`+= 1`, `-= 1`). Also the character keys are very close in the US
keyboard so it is easier to make a mistake and is not as simple as the
previous solution when I typed two times the same key. Using Erica's way of
saying certain things: I do not love the removal of `++` and `--`.

I do not know how far the Swift is to the adolescence, but it is certain
that teenagers are rebels. There's something very good at it. In most cases
they are to be certain. But in some things they regret later. Now I see
that many of us want to replace the `??` operator to something else. I'm
wondering the next steps... To replace the `&&`, `||` and `!` operator
with `and`, `or`, `not`? I’m not "loving" this as well.

Are these changes really necessary for the Swift evolution? Is it the
better path to deny its origin and to try to fix what is not broken? I
would like you to think about it.

There are many other things that really need to be improved and repaired
and other things needed to are created. Those mentioned here in this
message does not seem to fit it.

Regards,

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

[vmartinelli (Vanderlei Martinelli)]

Oops again: *activity

I have to learn to write in English some day... ;-)

···

On Sat, Jan 30, 2016 at 5:26 PM, Vanderlei Martinelli < vmartinelli@alecrim.com> wrote:

Radek, thank you for bringing this up, but I know the reasons they have
been removed and I read the older messages (the `&&`, `||` and `!`
operators mention was an intended hyperbole). I am aware of the “Swift
evolution process".

And I still do not agree with the removal. You can consider code like:

network.activiy++
doSomeNetworkActiviy()
network.activiy--

`activity` here does not need to be a numeric variable, but other thing.
Does not make sense to write...

network.activiy += 1
doSomeNetworkActiviy()
network.activiy -= 1

...since I cannot add or subtract more than 1 in any case.

Now we can use methods like `increment` or `decrement`, but the two words,
when reading, are similar and not clear as `++` and `--`.

OK, but my initial message intent is to prevent operator like `?:`, `??`
and others to go away too (and maybe bring back the `++` and `--`
operators, who knows?).

Best,
-Van

On Sat, Jan 30, 2016 at 5:05 PM, Radosław Pietruszewski <radexpl@gmail.com > > wrote:

Vanderlei,

The ++/— operators weren’t removed just because they are redundant with
`+= 1`.

++ is a bit special in that it doesn’t just modify the receiver, it also
returns the modified variable. What’s more, there’s this subtle difference
between `++foo` and `foo++` when you pass it further along. And that, that
difference, makes such use dangerous, and prone to bugs.

It’s also a useful feature — if you live in the world of C. But in Swift,
where explicit increments and decrements are far less common, it was deemed
that the slight utility and convenience of it does not justify the cost of
potential confusion and bugs that arise from that.

Give the actual proposal a read:
https://github.com/apple/swift-evolution/blob/master/proposals/0004-remove-pre-post-inc-decrement.md —
it does a pretty good job at explaining the disadvantages of ++ and —. It’s
not just a stylistic choice.

And &&, ||, !, are not in danger. Browse this mailing list’s history —
it’s been proposed more than once and immediately rejected as a change that
really isn’t justified in any way.

Also, let me quote Doug Gregor from the core team:

We certainly don’t want open-ended rehashing of past decisions, and I’d
like to have the baseline rule be something very close to “the core team’s
decisions are final” both to prevent such rehashing and also to emphasize
the seriousness of the public review process: the public review *is* the
point at which we need to gather widespread feedback on the direction of
the language. Determining that there is a problem “after we shipped it” is
a failure of the evolution process.

The evolution process has a number of stages (idea/proposal draft/public
review/core team), where each new stage brings additional scrutiny of the
proposal. The hope is that this scrutiny is enough to prevent us from
making poor decisions that may need to be overturned, and that the
swift-evolution community is representative enough of the larger Swift
community to provide that scrutiny. SE-0003 is somewhat special because
it’s one of a few changes for Swift 3 that were decided prior to
open-sourcing Swift: it didn’t go through the whole evolution process, so
it didn’t have as many eyes on it as language changes do now.

So, overall, I’d say that the core team’s decisions should be considered
effectively final. If something gets through the entire evolution process
and then we later find out it was a bad decision—e.g., due to massive
negative feedback when it reaches the wider Swift community or unforeseen
difficulties in implementation/rollout/etc.—the core team could bring up
the idea of backing out the change. However, the evolution process *should*
prevent this.

Best,
— Radek

On 30 Jan 2016, at 19:12, Vanderlei Martinelli via swift-evolution < >> swift-evolution@swift.org> wrote:

Hello everybody.

I see Swift as a member of “C family" (a granddaughter/grandson of C, a
daughter/son of Objective-C). OK, she/he is different and has her/his own
personality like a daughter/son should be and have, but I still like to see
Swift and recognize some traces that I know are things that became from C.

This said, I would like to say that after the removal of `++` and `--` my
code becomes less readable and more prone to errors. There were two
characters to differentiate an addition from a subtraction, now there is
only one (`+= 1`, `-= 1`). Also the character keys are very close in the US
keyboard so it is easier to make a mistake and is not as simple as the
previous solution when I typed two times the same key. Using Erica's way of
saying certain things: I do not love the removal of `++` and `--`.

I do not know how far the Swift is to the adolescence, but it is certain
that teenagers are rebels. There's something very good at it. In most cases
they are to be certain. But in some things they regret later. Now I see
that many of us want to replace the `??` operator to something else. I'm
wondering the next steps... To replace the `&&`, `||` and `!` operator
with `and`, `or`, `not`? I’m not "loving" this as well.

Are these changes really necessary for the Swift evolution? Is it the
better path to deny its origin and to try to fix what is not broken? I
would like you to think about it.

There are many other things that really need to be improved and repaired
and other things needed to are created. Those mentioned here in this
message does not seem to fit it.

Regards,

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

[vmartinelli (Vanderlei Martinelli)]

+1 for “community comments” period and a strong +1 for you now. :-)

···

On Sat, Jan 30, 2016 at 5:47 PM, Austin Zheng <austinzheng@gmail.com> wrote:

I think a "community comments" period for each review is a perfectly fine
idea :).

Doug Gregor's comments quoted below clearly state that accepted proposals
are meant to be final, precisely in order to avoid unending back-and-forth
counterproposals to things that people can never agree upon. However,
there's a good argument that the first proposals should be re-opened up for
community discussion, because they didn't go through the formal process.

Regarding "truly having a say": Swift is not designed by referendum; the
core team takes community feedback into account but is not bound by it when
making decisions re. the language. In every proposal rejection or
acceptance so far popularity (or lack thereof) has only been one of the
stated factors.

Best,
Austin

On Jan 30, 2016, at 11:41 AM, Vanderlei Martinelli < > vmartinelli@alecrim.com> wrote:

Strong -1 to people being so obtuse with other people discussing things in
a discussion group. ;-)

OK. I got your point. A “community comments” period may be a good
ideia, since "community" will not be used as a term to segregate those who
not have truly a say.

Regards,
-- Vanderlei Martinelli

On Sat, Jan 30, 2016 at 5:31 PM, Austin Zheng <austinzheng@gmail.com> > wrote:

Strong -1 to this proposal.

If your code is in dire need of ++/--, you can always define them
yourself using the language affordances. (Unlike, say, defining your own
C-style for loop.)

Other than that, ++/-- were a crufty legacy carryover from C, and their
disadvantages are adequately described in the rationale portion of the
proposal.

?? and ?: are in no imminent danger, and even if they were their removal
should be debated on the merits of those specific operators.

Finally, if people are going to try and re-open the pre-SE-0005 proposals
for retroactive discussion, maybe we should have a 'community comments'
period for each of them and just get it over with.

Austin

On Jan 30, 2016, at 10:12 AM, Vanderlei Martinelli via swift-evolution < >> swift-evolution@swift.org> wrote:

Hello everybody.

I see Swift as a member of “C family" (a granddaughter/grandson of C, a
daughter/son of Objective-C). OK, she/he is different and has her/his own
personality like a daughter/son should be and have, but I still like to see
Swift and recognize some traces that I know are things that became from C.

This said, I would like to say that after the removal of `++` and `--` my
code becomes less readable and more prone to errors. There were two
characters to differentiate an addition from a subtraction, now there is
only one (`+= 1`, `-= 1`). Also the character keys are very close in the US
keyboard so it is easier to make a mistake and is not as simple as the
previous solution when I typed two times the same key. Using Erica's way of
saying certain things: I do not love the removal of `++` and `--`.

I do not know how far the Swift is to the adolescence, but it is certain
that teenagers are rebels. There's something very good at it. In most cases
they are to be certain. But in some things they regret later. Now I see
that many of us want to replace the `??` operator to something else. I'm
wondering the next steps... To replace the `&&`, `||` and `!` operator
with `and`, `or`, `not`? I’m not "loving" this as well.

Are these changes really necessary for the Swift evolution? Is it the
better path to deny its origin and to try to fix what is not broken? I
would like you to think about it.

There are many other things that really need to be improved and repaired
and other things needed to are created. Those mentioned here in this
message does not seem to fit it.

Regards,

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

[Taras_Zakharko1 (Taras Zakharko)]

Back to the main topic: strongly opposed to reconsidering ++ and --. Rationale: as stated in the proposal.

Also, despite what Vanderlei suggests, Swift is certainly not a language from C family, unless you limit your analysis to syntax only. Its roots are much closer to Simula and ML. Yes, Swift has some similarities with C++, but mainly because C++ mixes C with concepts from Simula and ML (and probably others).

— Taras

···

On 30 Jan 2016, at 20:47, Austin Zheng via swift-evolution <swift-evolution@swift.org> wrote:

I think a "community comments" period for each review is a perfectly fine idea :).

Doug Gregor's comments quoted below clearly state that accepted proposals are meant to be final, precisely in order to avoid unending back-and-forth counterproposals to things that people can never agree upon. However, there's a good argument that the first proposals should be re-opened up for community discussion, because they didn't go through the formal process.

Regarding "truly having a say": Swift is not designed by referendum; the core team takes community feedback into account but is not bound by it when making decisions re. the language. In every proposal rejection or acceptance so far popularity (or lack thereof) has only been one of the stated factors.

Best,
Austin

On Jan 30, 2016, at 11:41 AM, Vanderlei Martinelli <vmartinelli@alecrim.com <mailto:vmartinelli@alecrim.com>> wrote:

Strong -1 to people being so obtuse with other people discussing things in a discussion group. ;-)

OK. I got your point. A “community comments” period may be a good ideia, since "community" will not be used as a term to segregate those who not have truly a say.

Regards,
-- Vanderlei Martinelli

On Sat, Jan 30, 2016 at 5:31 PM, Austin Zheng <austinzheng@gmail.com <mailto:austinzheng@gmail.com>> wrote:
Strong -1 to this proposal.

If your code is in dire need of ++/--, you can always define them yourself using the language affordances. (Unlike, say, defining your own C-style for loop.)

Other than that, ++/-- were a crufty legacy carryover from C, and their disadvantages are adequately described in the rationale portion of the proposal.

?? and ?: are in no imminent danger, and even if they were their removal should be debated on the merits of those specific operators.

Finally, if people are going to try and re-open the pre-SE-0005 proposals for retroactive discussion, maybe we should have a 'community comments' period for each of them and just get it over with.

Austin

On Jan 30, 2016, at 10:12 AM, Vanderlei Martinelli via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hello everybody.

I see Swift as a member of “C family" (a granddaughter/grandson of C, a daughter/son of Objective-C). OK, she/he is different and has her/his own personality like a daughter/son should be and have, but I still like to see Swift and recognize some traces that I know are things that became from C.

This said, I would like to say that after the removal of `++` and `--` my code becomes less readable and more prone to errors. There were two characters to differentiate an addition from a subtraction, now there is only one (`+= 1`, `-= 1`). Also the character keys are very close in the US keyboard so it is easier to make a mistake and is not as simple as the previous solution when I typed two times the same key. Using Erica's way of saying certain things: I do not love the removal of `++` and `--`.

I do not know how far the Swift is to the adolescence, but it is certain that teenagers are rebels. There's something very good at it. In most cases they are to be certain. But in some things they regret later. Now I see that many of us want to replace the `??` operator to something else. I'm wondering the next steps... To replace the `&&`, `||` and `!` operator with `and`, `or`, `not`? I’m not "loving" this as well.

Are these changes really necessary for the Swift evolution? Is it the better path to deny its origin and to try to fix what is not broken? I would like you to think about it.

There are many other things that really need to be improved and repaired and other things needed to are created. Those mentioned here in this message does not seem to fit it.

Regards,

-Van
_______________________________________________
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

[Haravikk3 (Haravikk)]

-1 from me.

I’m in favour of the removal for several reasons:

In many cases I’ve seen these operators use, the number is really used as an index type so should be encouraged to use the advance(), predecessor() and successor() methods for clarity.
I’ve seen numerous cases of tricky to diagnose bugs arising from foo++ and foo— being used in function calls and conditionals where a developer has misunderstood what value will actually be tested.
I’ve likewise seen ++foo and —foo misused in conditionals, particularly when foo is also present in the same conditional (or a function call) and a developer has misunderstood what value each instance of foo will result in. Plus it can easy to misread and result in some really hard to parse code when it comes to maintenance.
I think it makes sense for all assignment operators to include an equals and follow the same basic format. While lots of other languages may have these prefix and suffix operators, I like the idea of trying to keep operators to a useful minimum as standard.
It’s fairly easy to just add them yourself if you really can’t part with them.

Of course I’ve seen them used reasonably, but that’s mostly in things like loops where Swift provides a lot of good alternatives, plus the aforementioned index protocol. The rest of the time they’re often (in my experience) misused to create shorter, but not necessarily neater code, and can lead to a lot of silly, subtle errors.

That said I’m not hugely bothered either way (if they’re left in then I can just continue to not use them), but I think the reasoning for cutting them is sound.

[trs (Thorsten Seitz)]

Radek, thank you for bringing this up, but I know the reasons they have been removed and I read the older messages (the `&&`, `||` and `!` operators mention was an intended hyperbole). I am aware of the “Swift evolution process".

And I still do not agree with the removal. You can consider code like:

network.activiy++
doSomeNetworkActiviy()
network.activiy—-

`activity` here does not need to be a numeric variable, but other thing. Does not make sense to write...

network.activiy += 1
doSomeNetworkActiviy()
network.activiy -= 1

...since I cannot add or subtract more than 1 in any case.

Now we can use methods like `increment` or `decrement`, but the two words, when reading, are similar and not clear as `++` and `—`.

For something like this I’d rather encapsulate this pattern of incrementing while an activity happens to ensure that the activity count is really decremented thereafter, i.e. something like the following (insert some better name for the method)

extension Network {

  func incrementActivityCountWhile(@noescape action: Void -> Void) {
    self.activity += 1 // or increment()
    defer { self.activity -= 1 } // or decrement()
    action()
  }
}

which can then be used like follows:

network.incrementActivityCountWhile {
  doSomeNetworkActivity()
}

The point being that incrementing and decrementing are only written once (and the method probably being unit tested) and therefore the risk of errors creeping in is close to zero.

OK, but my initial message intent is to prevent operator like `?:`, `??` and others to go away too (and maybe bring back the `++` and `--` operators, who knows?).

I agree with you there with regards to keeping these operators (and just dropping the prefix version and making the postfix version void would indeed have been a nice solution for ++ and -- but I didn’t object in the review, so that ship has sailed and I don’t think it’s a big problem; there are more important things to be done).

Actually I didn’t have the impression that many people wanted to drop `??`. Actually I got just the opposite impression.

-Thorsten

···

Am 30.01.2016 um 20:26 schrieb Vanderlei Martinelli via swift-evolution <swift-evolution@swift.org>:

Best,
-Van

On Sat, Jan 30, 2016 at 5:05 PM, Radosław Pietruszewski <radexpl@gmail.com <mailto:radexpl@gmail.com>> wrote:
Vanderlei,

The ++/— operators weren’t removed just because they are redundant with `+= 1`.

++ is a bit special in that it doesn’t just modify the receiver, it also returns the modified variable. What’s more, there’s this subtle difference between `++foo` and `foo++` when you pass it further along. And that, that difference, makes such use dangerous, and prone to bugs.

It’s also a useful feature — if you live in the world of C. But in Swift, where explicit increments and decrements are far less common, it was deemed that the slight utility and convenience of it does not justify the cost of potential confusion and bugs that arise from that.

Give the actual proposal a read: https://github.com/apple/swift-evolution/blob/master/proposals/0004-remove-pre-post-inc-decrement.md — it does a pretty good job at explaining the disadvantages of ++ and —. It’s not just a stylistic choice.

And &&, ||, !, are not in danger. Browse this mailing list’s history — it’s been proposed more than once and immediately rejected as a change that really isn’t justified in any way.

Also, let me quote Doug Gregor from the core team:

We certainly don’t want open-ended rehashing of past decisions, and I’d like to have the baseline rule be something very close to “the core team’s decisions are final” both to prevent such rehashing and also to emphasize the seriousness of the public review process: the public review is the point at which we need to gather widespread feedback on the direction of the language. Determining that there is a problem “after we shipped it” is a failure of the evolution process.

The evolution process has a number of stages (idea/proposal draft/public review/core team), where each new stage brings additional scrutiny of the proposal. The hope is that this scrutiny is enough to prevent us from making poor decisions that may need to be overturned, and that the swift-evolution community is representative enough of the larger Swift community to provide that scrutiny. SE-0003 is somewhat special because it’s one of a few changes for Swift 3 that were decided prior to open-sourcing Swift: it didn’t go through the whole evolution process, so it didn’t have as many eyes on it as language changes do now.

So, overall, I’d say that the core team’s decisions should be considered effectively final. If something gets through the entire evolution process and then we later find out it was a bad decision—e.g., due to massive negative feedback when it reaches the wider Swift community or unforeseen difficulties in implementation/rollout/etc.—the core team could bring up the idea of backing out the change. However, the evolution process *should* prevent this.

Best,
— Radek

On 30 Jan 2016, at 19:12, Vanderlei Martinelli via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hello everybody.

I see Swift as a member of “C family" (a granddaughter/grandson of C, a daughter/son of Objective-C). OK, she/he is different and has her/his own personality like a daughter/son should be and have, but I still like to see Swift and recognize some traces that I know are things that became from C.

This said, I would like to say that after the removal of `++` and `--` my code becomes less readable and more prone to errors. There were two characters to differentiate an addition from a subtraction, now there is only one (`+= 1`, `-= 1`). Also the character keys are very close in the US keyboard so it is easier to make a mistake and is not as simple as the previous solution when I typed two times the same key. Using Erica's way of saying certain things: I do not love the removal of `++` and `--`.

I do not know how far the Swift is to the adolescence, but it is certain that teenagers are rebels. There's something very good at it. In most cases they are to be certain. But in some things they regret later. Now I see that many of us want to replace the `??` operator to something else. I'm wondering the next steps... To replace the `&&`, `||` and `!` operator with `and`, `or`, `not`? I’m not "loving" this as well.

Are these changes really necessary for the Swift evolution? Is it the better path to deny its origin and to try to fix what is not broken? I would like you to think about it.

There are many other things that really need to be improved and repaired and other things needed to are created. Those mentioned here in this message does not seem to fit it.

Regards,

-Van
_______________________________________________
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

[Jonathan_Tang]

FWIW, Python has no ++ and -- operators (you have to use += 1 or -= 1), and
nobody misses them there. Once you introduce for-each loops, about 99% of
the usage sites for ++ disappear, and it quickly fades out of your muscle
memory.

It used to get re-introduced every so often by having to work with C, Java,
and Javascript, but now ES6, Java, Objective-C, PHP, Python, Ruby, Go,
Rust, and even C++ all have for-each loops or iteration blocks, so there's
basically no need for regular for-loops or increment operators in any
language but C.

···

On Sun, Jan 31, 2016 at 6:19 AM, Tino Heth via swift-evolution < swift-evolution@swift.org> wrote:

I do not know how far the Swift is to the adolescence, but it is certain
that teenagers are rebels. There's something very good at it. In most cases
they are to be certain. But in some things they regret later.

Children have to learn their own lessons — and I guess re-adding "++"
wouldn't be as complicated as a big tattoo on your neck ;-)

My first thought on the removal was "we'll see many custom post-increment
operators soon", and that may be true; but in the meantime, I came to the
conclusion that I won't define those custom operators, but rather configure
my system to replace "++" with " += 1":
Typing the old operator is definitely faster, but I don't mind if it's
turned into something else automatically (when there is no performance gain
for pre-increment, I've always preferred the post-variants).

[vmartinelli (Vanderlei Martinelli)]

About who are the parents: our two views are complementary, I believe. But,
remember you have to use C += 1 and not C++ now. ;-)

···

On Sat, Jan 30, 2016 at 5:58 PM, Taras Zakharko <taras.zakharko@uzh.ch> wrote:

Back to the main topic: strongly opposed to reconsidering ++ and --.
Rationale: as stated in the proposal.

Also, despite what Vanderlei suggests, Swift is certainly not a language
from C family, unless you limit your analysis to syntax only. Its roots are
much closer to Simula and ML. Yes, Swift has some similarities with C++,
but mainly because C++ mixes C with concepts from Simula and ML (and
probably others).

— Taras

On 30 Jan 2016, at 20:47, Austin Zheng via swift-evolution < > swift-evolution@swift.org> wrote:

I think a "community comments" period for each review is a perfectly fine
idea :).

Doug Gregor's comments quoted below clearly state that accepted proposals
are meant to be final, precisely in order to avoid unending back-and-forth
counterproposals to things that people can never agree upon. However,
there's a good argument that the first proposals should be re-opened up for
community discussion, because they didn't go through the formal process.

Regarding "truly having a say": Swift is not designed by referendum; the
core team takes community feedback into account but is not bound by it when
making decisions re. the language. In every proposal rejection or
acceptance so far popularity (or lack thereof) has only been one of the
stated factors.

Best,
Austin

On Jan 30, 2016, at 11:41 AM, Vanderlei Martinelli < > vmartinelli@alecrim.com> wrote:

Strong -1 to people being so obtuse with other people discussing things in
a discussion group. ;-)

OK. I got your point. A “community comments” period may be a good
ideia, since "community" will not be used as a term to segregate those who
not have truly a say.

Regards,
-- Vanderlei Martinelli

On Sat, Jan 30, 2016 at 5:31 PM, Austin Zheng <austinzheng@gmail.com> > wrote:

Strong -1 to this proposal.

If your code is in dire need of ++/--, you can always define them
yourself using the language affordances. (Unlike, say, defining your own
C-style for loop.)

Other than that, ++/-- were a crufty legacy carryover from C, and their
disadvantages are adequately described in the rationale portion of the
proposal.

?? and ?: are in no imminent danger, and even if they were their removal
should be debated on the merits of those specific operators.

Finally, if people are going to try and re-open the pre-SE-0005 proposals
for retroactive discussion, maybe we should have a 'community comments'
period for each of them and just get it over with.

Austin

On Jan 30, 2016, at 10:12 AM, Vanderlei Martinelli via swift-evolution < >> swift-evolution@swift.org> wrote:

Hello everybody.

I see Swift as a member of “C family" (a granddaughter/grandson of C, a
daughter/son of Objective-C). OK, she/he is different and has her/his own
personality like a daughter/son should be and have, but I still like to see
Swift and recognize some traces that I know are things that became from C.

This said, I would like to say that after the removal of `++` and `--` my
code becomes less readable and more prone to errors. There were two
characters to differentiate an addition from a subtraction, now there is
only one (`+= 1`, `-= 1`). Also the character keys are very close in the US
keyboard so it is easier to make a mistake and is not as simple as the
previous solution when I typed two times the same key. Using Erica's way of
saying certain things: I do not love the removal of `++` and `--`.

I do not know how far the Swift is to the adolescence, but it is certain
that teenagers are rebels. There's something very good at it. In most cases
they are to be certain. But in some things they regret later. Now I see
that many of us want to replace the `??` operator to something else. I'm
wondering the next steps... To replace the `&&`, `||` and `!` operator
with `and`, `or`, `not`? I’m not "loving" this as well.

Are these changes really necessary for the Swift evolution? Is it the
better path to deny its origin and to try to fix what is not broken? I
would like you to think about it.

There are many other things that really need to be improved and repaired
and other things needed to are created. Those mentioned here in this
message does not seem to fit it.

Regards,

-Van
_______________________________________________
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