[swift-evolution] [swift-evolution-announce] [Review] SE-0024 "Optional Value Setter `??=`"

[Kevin Ballard]

On Fri, Feb 12, 2016, at 09:15 PM, Douglas Gregor wrote:
>  * What is your evaluation of the proposal?
-1. If we were to have this operator, then I think `??=` is a good
choice for it. But I don't think we need this operator. As others have
pointed out, a lot of the use-cases from other languages don't actually
work in Swift, and having the operator encourages people to write anti-
patterns in order to use it, such as making a value into a mutable
Optional when it really should be an immutable non-optional value.

>  * Is the problem being addressed significant enough to warrant a
>    change to Swift?
No. The need for this sort of operator is much rarer in Swift than it is
in languages that do have an equivalent (like Ruby).

Anecdotally, I've written a lot of Swift code at this point, and I've
never wanted this. I have on rare occasion wanted a local "lazy"
variable, but in those rare instances, the desire was to move the
initialization out of the main body of the function and up to the
declaration, which `??=` doesn't help with.

>  * Does this proposal fit well with the feel and direction of Swift?
The choice of operator I think is reasonable, given the existing `??`
operator, but encouraging the use of Optionals for local variables that
will end up with a guaranteed-non-Optional value does not.

>  * If you have used other languages or libraries with a similar
>    feature, how do you feel that this proposal compares to those?
The only languages that I know of with a similar operator also return
the rhs value from the assignment expression, and that's not something
Swift would do. So this is less useful than the operator in those
languages.

>  * How much effort did you put into your review? A glance, a quick
>    reading, or an in-depth study?
A quick reading.

-Kevin Ballard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160216/ffdabee3/attachment.html>