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

Sat Jan 30 16:46:58 CST 2016

> Am 30.01.2016 um 20:26 schrieb Vanderlei Martinelli via swift-evolution <swift-evolution at swift.org>:
> 
> 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

> Best,
> -Van
> 
> 
> On Sat, Jan 30, 2016 at 5:05 PM, Radosław Pietruszewski <radexpl at gmail.com <mailto: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 <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 <mailto: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 <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
> _______________________________________________
> 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/3b297cfb/attachment.html>