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

Vanderlei Martinelli vmartinelli at alecrim.com
Sat Jan 30 13:49:09 CST 2016

+1 for “community comments” period and a strong +1 for you now. :-)

On Sat, Jan 30, 2016 at 5:47 PM, Austin Zheng <austinzheng at gmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160130/97b99ec5/attachment.html>

More information about the swift-evolution mailing list