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

I would disagree that Swift is mixing C with concepts of ML….. Swift is actually for the most part resistant to adopting functional paradigm — opting only to include a few minor functional decorations.

···

On 2016-01-31, at 2:58:32, Taras Zakharko via swift-evolution <swift-evolution@swift.org> 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 <mailto: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 <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

Well... I continue writing code with Swift 2.2 and I'm not loving the fact
I cannot use ++ or -- anymore (and no, I'm not using the operators in
loops, I mean things like responding to UIPageViewController data source,
etc).

And what if we remove `+=` and `-=` as well? It's so C... What if can write
code with COBOL-style like this?

ADD 1 TO MY-AWESOME-VARIABLE.
SUBTRACT 1 FROM MY-AWESOME-VARIABLE.

And look that we are not adding a `WORKING-STORAGE SECTION` or a `PROCEDURE
DIVISION` here...

Do not take it seriously, OK? It was just a joke (a bad taste joke,
perhaps). ;-)

-Van

···

On Sun, Jan 31, 2016 at 10:39 PM, Jonathan Tang <jonathan.d.tang@gmail.com> wrote:

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).

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.

Can the ++/-- removal be done in a way that someone could add them back
(3.0) and suppress the warnings (2.2)?

···

On Sat, Jan 30, 2016 at 12:07 PM, Taras Zakharko via swift-evolution < swift-evolution@swift.org> wrote:

I was not necessarily talking about functional paradigm when I mentioned
ML as influence for Swift, more about type system. Anyway, I think this
discussion is best kept to a different list.

— Taras

On 30 Jan 2016, at 21:02, Craig Cruden <ccruden@novafore.com> wrote:

I would disagree that Swift is mixing C with concepts of ML….. Swift is
actually for the most part resistant to adopting functional paradigm —
opting only to include a few minor functional decorations.

On 2016-01-31, at 2:58:32, Taras Zakharko via swift-evolution < > swift-evolution@swift.org> 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

_______________________________________________
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

I was not necessarily talking about functional paradigm when I mentioned ML as influence for Swift, more about type system. Anyway, I think this discussion is best kept to a different list.

— Taras

···

On 30 Jan 2016, at 21:02, Craig Cruden <ccruden@novafore.com> wrote:

I would disagree that Swift is mixing C with concepts of ML….. Swift is actually for the most part resistant to adopting functional paradigm — opting only to include a few minor functional decorations.

On 2016-01-31, at 2:58:32, Taras Zakharko via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 <mailto: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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

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