[swift-evolution] Reconsider ++ and -- operators removal and prevent other well-known operators from change

Sat Jan 30 13:26:17 CST 2016

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 at 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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160130/18fc8016/attachment.html>