[swift-evolution] Optional Setting

[Stephen Celis]

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.

Stephen

On Wed, Dec 16, 2015 at 9:28 AM, Marc Knaup via swift-evolution <
swift-evolution at swift.org> wrote:

> I'm still uncertain whether that would solve the issue at the right
> location.
>
> How do you end up in such a situation where this is actually necessary?
> Why do I not end up in such situations?
> I'd like to understand where the discrepancy comes from.
>
> I.e. where do you define chatTitleName? Where else do you set
> chatTitleName?
> Why isn't it initially set to "Default" an then overwritten on-demand?
>
> On Wed, Dec 16, 2015 at 3:22 PM, Kevin Wooten <kdubb at me.com> wrote:
>
>>
>> On Dec 16, 2015, at 4:12 AM, Al Skipp via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> On 16 Dec 2015, at 00:58, Marc Knaup via swift-evolution <
>> 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
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
>
> _______________________________________________
> 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/20151216/17de30f5/attachment.html>