[swift-evolution] ++ and --

[Austin Zheng]

This pre-proposal needs to answer a few questions before it can really go
anywhere:

- What sort of mechanism can ++/-- exploit, that "+= 1" or "-= 1" can't, to
make the former perform better than the latter? It would be helpful to have
at least a vague idea as to whether this is even possible, or else the
proposal is meaningless.

- Exactly how is adding in a faster ++/-- operator going to address Swift's
performance problems? For example, how is ++/-- going to make arrays
perform better?

- Why were the (multiple) arguments made in favor of the proposal to remove
++/-- weak or incorrect? What arguments in favor of keeping ++/-- are
stronger than their counterparts?

Best,
Austin


On Wed, Mar 23, 2016 at 6:44 PM, Biala via swift-evolution <
swift-evolution at swift.org> wrote:

> Hello,
>
> I would like to share my opinion on -- and ++ operators...
>
> I think that ++ and — should stay and MUST be implemented as faster
> operations than += and -=.They have very specific job after all and that is
> the general understanding. If you fail to implement them as faster
> operators that will really look as major weakness of SWIFT development
> team. Swift is still too slow – try working with Arrays so having these
> faster operators that are very commonly used will be a plus. Another plus
> will be that you will not break tons of existing code. Breaking existing
> code is always considered as an architecture weakness and always have a
> negative impact on the whole developers community – take a look at
> Microsoft for example they often do that mistake…. Android on the other
> hand is till that moment always building over the old (however they make
> other mistakes [image: 😉]
>
> _______________________________________________
> 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/20160323/8fd49f81/attachment.html>