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

Sat Feb 13 08:59:38 CST 2016

I disagree. I think those are exactly the wrong use cases for ??= and, in fact, could be used as an argument against this proposal (??= encouraging unidiomatic behavior).

> let object = try? UnsupportedMessage(text: "James", type:.Text, date:NSDate()) ?? FailedObject()
> 
> vs
> 
> var object = try? Message(text: "James", type:.Text, date:NSDate())
> object ??= UnsupportedMessage()

The first example — though an admittedly long line — is clearly better to my eyes.

The second one does *two* things considered undesirable in Swift:

- it creates a mutable variable even though it’s not necessary
- it leaves `object` as an Optional, even though we don’t mean it to actually ever be nil.

> This could also be great for the null object pattern where you may not want a variable to be nil, you may want some sort of null object that is vended in cases of failure that could log this error.

I agree with the premise — a null object or value is often much better than a nil (e.g. [] vs nil when there isn’t a semantic diff between the two). But when you use ??=, the variable you’re mutating is still an Optional and could be nil!

* * *

I see two reasons to use ??=:

- when applying a default value to a dictionary (or a dictionary-like structure), since subscripting it will produce Optionals *either way*
- when mutating a property (not a local variable!), that is (has to be) optional and mutable *either way*

It’s a useful shortcut in those two circumstances. But it is not desirable to damage our Swift code with needless optionals or mutability so we can use ??=.

best,
— Radek

> On 13 Feb 2016, at 13:10, James Campbell <james at supmenow.com> wrote:
> 
> One common case could be for a error catching, consider this:
> 
> let object = try? UnsupportedMessage(text: "James", type:.Text, date:NSDate()) ?? FailedObject()
> 
> vs
> 
> var object = try? Message(text: "James", type:.Text, date:NSDate())
> object ??= UnsupportedMessage()
> 
> Why would we need this? I have a chat application where if it gets a message it doesn't understand it will throw an error. In the past I would handle this errors by returning nil like so. However we want to communicate to the user that they missing content by vending a UnsupportedMessage object which shows the UI to prompt them to upgrade.
> 
> If the object being constructed has a lot of variables then it could be lost off the side of the screen. I feel ??= is more concise in this case.
> 
> This could also be great for the null object pattern where you may not want a variable to be nil, you may want some sort of null object that is vended in cases of failure that could log this error.
> 
> ___________________________________
> 
> James⎥Head of Awesome
> 
> james at supmenow.com <mailto:james at supmenow.com>⎥supmenow.com <http://supmenow.com/>
> Sup
> 
> Runway East > 
> 
> 10 Finsbury Square
> 
> London
> 
>  > EC2A 1AF 
> 
> 
> On Sat, Feb 13, 2016 at 11:20 AM, Taras Zakharko via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> I think the proposal should include some discussion on the common cases where this operator would be useful. As such, I don’t see much hard of including this, except that I am not sure that the problem is significant enough to warrant a reaction. 
> 
> — T
> 
> 
>> On 13 Feb 2016, at 11:11, Radosław Pietruszewski via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> +0.5
>> 
>> I am generally for this proposal, because I don’t see why not — there are cases where this is useful, and it’s symmetric with other X/X= operator pairs, so it’s not like it’s a completely new thing.
>> 
>> However, I don’t think the operator is _as_ useful in Swift as it is in other languages.
>> 
>> In Ruby, for example, it’s extremely common to use `||=` (an equivalent of ??=, more or less) to modify function arguments, e.g. assign default values if nil was passed. But you can’t do that in Swift since SE-0003 removed the ability to mark a parameter as `var`.
>> 
>> So you can’t do that
>> 
>> 	arg ??= default
>> 
>> and you have to do
>> 
>> 	let arg = arg ?? default
>> 
>> Except you wouldn’t want the earlier version anyway, because `arg` would continue to be an optional. A notion not relevant in a dynamically typed language, but in Swift, it matters.
>> 
>> And I see other cases like this. A proposal to add `??=` to Swift was one of the first Swift radars I filed, because it was just something I was really used to. But with time I realized there are actually relatively few cases where this is useful. And that’s all because of Swift’s characteristics: it’s statically typed, it pushes you to use constants and not variables where possible, optionality is explicit, and avoided when not necessary.
>> 
>> Still, I searched through my code and found _a few_ instances of `??=` (my own implementation), almost all used for dealing with dictionaries (and a dictionary-like structure in a library called SwiftyUserDefaults) — and having this operator definitely improved the clarity of those places.
>> 
>>> What is your evaluation of the proposal?
>> 
>> All in all, I’m for.
>> 
>>> Is the problem being addressed significant enough to warrant a change to Swift?
>> 
>> I’d say yes, because it’s simple to implement, and carries little risk AFAICT. Still, it’s not as significant an improvement as many of the other proposals.
>> 
>>> Does this proposal fit well with the feel and direction of Swift?
>> 
>> Again, ??= is only useful in _some_ cases, and in many other cases you want to avoid optionality and mutability. So it’s not necessarily something we want to encourage a lot, but I don’t see real risk in people trying to damage their Swift code just so they can use ??=. And OTOH having nice tools for dealing with optionality when it’s necessary is a very Swifty thing to do, so overall, yes.
>> 
>>> If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
>> Mostly dynamically typed languages with ||=, Ruby in particular. Also my own implementation of ??= in my projects and https://github.com/radex/swiftyuserdefaults <https://github.com/radex/swiftyuserdefaults>
>>> How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
>> A quick reading of the proposal.
>> 
>> Best,
>> — Radek
>> 
>>> On 13 Feb 2016, at 06:15, Douglas Gregor via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> Hello Swift community,
>>> 
>>> The review of SE-0024 "Optional Value Setter `??=`" begins now and runs through February 18, 2016. The proposal is available here:
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0024-optional-value-setter.md <https://github.com/apple/swift-evolution/blob/master/proposals/0024-optional-value-setter.md>
>>> Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at
>>> 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:
>>> 
>>> Proposal link:
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0024-optional-value-setter.md <https://github.com/apple/swift-evolution/blob/master/proposals/0024-optional-value-setter.md>
>>> Reply text
>>> 
>>> Other replies
>>>  <https://github.com/apple/swift-evolution#what-goes-into-a-review-1>What goes into a review?
>>> 
>>> The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
>>> 
>>> What is your evaluation of the proposal?
>>> Is the problem being addressed significant enough to warrant a change to Swift?
>>> Does this proposal fit well with the feel and direction of Swift?
>>> If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
>>> How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
>>> More information about the Swift evolution process is available at
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/process.md <https://github.com/apple/swift-evolution/blob/master/process.md>
>>> Thank you,
>>> 
>>> Doug Gregor
>>> 
>>> Review Manager
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160213/02b39c2b/attachment.html>