[swift-evolution] Optional Setting

[Jacob Bandes-Storch]

I agree it wouldn't/shouldn't be different. But it's worth mentioning in
the proposal.

Jacob Bandes-Storch

On Wed, Dec 16, 2015 at 2:04 PM, Marc Knaup via swift-evolution <
swift-evolution at swift.org> wrote:

> The threading issue affects all operators like +=, -=, *= etc. and they
> are not going to be removed.
> I don't think ??= would be any different in this case.
>
> On Wed, Dec 16, 2015 at 10:58 PM, Javier Soto via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> I think it would be worth mentioning in the proposal the threading
>> implications of this operator. The trickyness comes from the fact that
>> suddenly that expression is performing a call to both the getter *and* the
>> setter, so even if those 2 were to be protected via locks, there's still
>> the possibility of race-conditions. Someone else mentioned this is of
>> course also the case with operators such as ++ (which I believe Lattner was
>> in favor of stripping from the language)
>>
>> Not saying that this operator shouldn't exist for this reason, but I do
>> think it's important to realize the complexity it brings to add an operator
>> that does more than is immediately obvious, since that's often times a
>> recipe for any developer making this sort of mistake.
>> I would lean towards -1, but I do acknowledge that in some circumstances
>> it can simplify some code.
>>
>> On Wed, Dec 16, 2015 at 8:50 AM James Campbell via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>> I've started a formal proposal here:
>>>
>>> https://github.com/apple/swift-evolution/pull/63
>>>
>>> On Wed, Dec 16, 2015 at 4:48 PM, Dave Abrahams via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>>
>>>>
>>>> On Dec 16, 2015, at 6:22 AM, Kevin Wooten via swift-evolution <
>>>> swift-evolution at swift.org> 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.
>>>>
>>>>
>>>> A few points:
>>>>
>>>> 1. I've always thought we needed something like this; glad to see it
>>>> discussed
>>>>
>>>> 2. This is also applicable to dictionaries:
>>>>
>>>>   messagesViewController.titleNames["chat"] ??= "Default"
>>>>
>>>> 3. I think it may be time for a formal proposal :-)
>>>>
>>>> 4. One way the community can help us to evaluate it would be to create
>>>> the API in an extension in your own code, actually apply it in your
>>>> project, and evaluate what it does for readability.
>>>>
>>>> Thanks,
>>>>
>>>> -Dave
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>>
>>>
>>>
>>> --
>>>  Wizard
>>> james at supmenow.com
>>> +44 7523 279 698
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>> --
>> Javier Soto
>> _______________________________________________
>> 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/de53bb44/attachment.html>