[swift-evolution] Optional Setting

Kevin Wooten kdubb at me.com
Wed Dec 16 09:23:53 CST 2015


> On Dec 16, 2015, at 8:03 AM, Stephen Celis <stephen.celis at gmail.com> wrote:
> 
> While I used `||=` in Ruby all the time, where everything can be `nil`, I've found that Swift's Optional model is different enough that I've never really desired a `??=`, so I'm a -1 for the proposal, as I see it encouraging the use of optionals where a non-optional would be preferred.
> 
> With the `chatTitleName` example, I'd probably make `"Default"` the default argument on initialization (and make it so `chatTitleName` is not optional), or I'd move the `chatTitleName ?? "Default"` into the presentation logic.
> 

Well I was using real variable names but the example was contrived; I should have made that clearer.  Also, I didn’t mean to sound like I was in clear support of this addition. I was really just putting it into context with regard to variables names where we’ve used “??”. 

In reality my vote is.. ±0

> Stephen
> 
> On Wed, Dec 16, 2015 at 9:28 AM, Marc Knaup via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> I'm still uncertain whether that would solve the issue at the right location.
> 
> On Wed, Dec 16, 2015 at 3:22 PM, Kevin Wooten <kdubb at me.com <mailto:kdubb at me.com>> wrote:
> 
>> On Dec 16, 2015, at 4:12 AM, Al Skipp via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> On 16 Dec 2015, at 00:58, Marc Knaup via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> I tend towards -1 for multiple reasons:
>>> It has little value for local variables. In most cases you want to use the value you assign to a local variable and assigning it to an optional variable would require a subsequent unwrapping. In most cases where local variables are involved "var x = y ?? z" is satisfying as it creates a non-optional value iff z is non-optional.
>>> 
>>> It seems to be a rare use case that you set a value of an optional property which is currently nil and without also using that value directly within the same context. Quickly checking my Swift apps reveals only very little such use cases.
>>> 
>>> The remaining cases could expressed like "object.property = object.property ?? …" or using "if object.property == nil { … }".
>>> While it is true that variable and property name could be very long, this is an unlikely case of an already rare case which decreases the value of the proposed assignment operator even further.
>>> 
>>> Most important though is that such an optional assignment operator would work differently from all other assignment operators. The right operand would never be executed if the variable being assigned is already non-nil. This will likely be unexpected for a lot of developers who expect similar behavior like in all other assignments.
>> I think these are all very good points. Seems like the only really practical use would be restricted to:
>> object.property ??= val
>> 
>> Instead of:
>> object.property = object.property ?? val
>> 
>> Is it worth it for that one scenario? As Marc pointed out, the ?? operator is much more versatile as it can also be used to return a non-optional value.
> 
> After perusing our Swift code it turns out that we use the long form (a = a ?? def) quite a bit.  As it was previously mentioned it, when the variables is named “a” it’s clearly not an issue, but this is…
> 
>     messagesViewController.chatTitleName =  messagesViewController.chatTitleName ?? “Default”
> 
> (Those are effectively real world variable names). 
> 
> I think quite a bit of the clarity of this statement is lost by the duplication and the proposed form..
> 
>     messagesViewController.chatTitleName ??= “Default”
> 
> clears it up fairly well.
> 
>> _______________________________________________
>> 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/20151216/14490616/attachment.html>


More information about the swift-evolution mailing list