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

Sat Jan 30 13:33:52 CST 2016

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 at 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 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/3a3d4b34/attachment.html>