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

[David Turnbull]

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 at 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 at 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 at 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 at 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 at 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 at 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 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
>>
>>
>>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> 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
>
>
>
>
> _______________________________________________
> 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/8f5f8e7f/attachment.html>