And I still do not agree with the removal. You can consider code like:
`activity` here does not need to be a numeric variable, but other thing.
Does not make sense to write...
...since I cannot add or subtract more than 1 in any case.
The ++/— operators weren’t removed just because they are redundant with
++ 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:
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*
On 30 Jan 2016, at 19:12, Vanderlei Martinelli via swift-evolution < >> firstname.lastname@example.org> wrote:
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.
swift-evolution mailing list