[swift-evolution] Optional Setting

[Jacob Bandes-Storch]

Would there be any caveats in introducing something like this, given the
raciness of the operator? I guess it's not really a big deal — the other
compound assignment operators (+=, -=, etc.) have the same problem.

I'm not hearing much argument; sounds like many are in favor. I'd be happy
to flesh out my radar into a "??=" proposal this evening, or someone else
can do it if they'd like.

Jacob

On Tue, Dec 15, 2015 at 4:12 PM, Jordan Rose <jordan_rose at apple.com> wrote:

> It's possible that @_transparent
> <https://github.com/apple/swift/blob/master/docs/TransparentAttr.rst> is
> handled early enough in the compiler that we actually would get this
> behavior. I'm not sure, though.
>
> +1 from me whether or not didSet is always called, though. "a = a ?? b"
> always calls didSet anyway.
>
> Jordan
>
> P.S. There's nothing particularly useful in the Radar, except that
> together with the dups there are three suggested spellings: "=?", "?=", and
> "??=". My vote is with Brent for "??=".
>
> On Dec 15, 2015, at 15:26 , James Campbell via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> :) Wasn't expecting it to be trivial. but yeah if it could somehow be
> short circuited so didSet, willSet isn't called when there is a value
> already. that would be awesome.
>
> Could the willSet, didSet behaviour  be tied to the = behaviour ?  in your
> example above the operation ultimately cascades into a = operation.
>
> Same with operations such as *= or /= ultimately it has to do a =
> operation to set the new calculated value.
>
> On Tue, Dec 15, 2015 at 11:23 PM, Jacob Bandes-Storch <jtbandes at gmail.com>
>  wrote:
>
>> I agree that would be nice. Just pointing out that it's nontrivial. If
>> you implement this custom operator today, you get different behavior.
>>
>> Jacob
>>
>> On Tue, Dec 15, 2015 at 3:21 PM, James Campbell <james at supmenow.com>
>> wrote:
>>
>>> If it has a value already the nit wouldn't call anything as it
>>> technically hasn't been set. Only if it already has a value does it try and
>>> set something in which case the didSet is called :)
>>>
>>> On Tue, Dec 15, 2015 at 11:16 PM, Jacob Bandes-Storch via swift-evolution
>>>  <swift-evolution at swift.org> wrote:
>>>
>>>> One possible caveat is with custom setters.
>>>>
>>>> If "a" already has a value, does "a ??= b" call the custom
>>>> setter/willSet/didSet, or does it see the nil and short-circuit?
>>>>
>>>> This can be implemented today:
>>>>
>>>>     func ??=(inout lhs: T?, @autoclosure rhs: () -> T?) { if lhs ==
>>>> nil { lhs = rhs() } }
>>>>
>>>> However, the use of "inout" will always cause the didSets to be
>>>> triggered at the call site, when just using if-statements instead wouldn't
>>>> have done so.
>>>>
>>>> Jacob
>>>>
>>>> On Tue, Dec 15, 2015 at 3:10 PM, Brent Royal-Gordon via swift-evolution
>>>>  <swift-evolution at swift.org> wrote:
>>>>
>>>>> > I think that the existing syntax for “??” handles this need fairly
>>>>> well without requiring an additional assignment operator:
>>>>> >
>>>>> >       a = a ?? []
>>>>>
>>>>> When the variable is `a`, sure. When it’s
>>>>> `scoreboardViewController.selectedScoreboard`, not so much.
>>>>>
>>>>> +1 from me, though I prefer the `??=` spelling to match the `??`
>>>>> operator more closely.
>>>>>
>>>>> --
>>>>> Brent Royal-Gordon
>>>>> Architechies
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>>
>>>
>>>
>>> --
>>>  Wizard
>>> james at supmenow.com
>>> +44 7523 279 698
>>>
>>
>>
>
>
> --
>  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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151215/c777fcb6/attachment.html>