[swift-evolution] Optional Setting

Marc Knaup marc at knaup.koeln
Tue Dec 15 18:58:58 CST 2015 

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.


On Wed, Dec 16, 2015 at 1:39 AM, James Campbell via swift-evolution <
swift-evolution at swift.org> wrote:

> Can you guys give me tips on how to improve this PR
> https://github.com/apple/swift-evolution/pull/63 first time writing a
> proposal or anything to do with a language. Let me know if there are points
> I missed.
>
> On Wed, Dec 16, 2015 at 12:26 AM, James Campbell <james at supmenow.com>
> wrote:
>
>> On second thoughts, I'm preparing one :)
>>
>> On Wed, Dec 16, 2015 at 12:24 AM, James Campbell <james at supmenow.com>
>> wrote:
>>
>>> Cool would be happy for you to do it :)  if you time, almost night here
>>> so :) but happy for you to quote me in the proposal.
>>>
>>>
>>>
>>> On Wed, Dec 16, 2015 at 12:17 AM, Jacob Bandes-Storch <
>>> jtbandes at gmail.com> wrote:
>>>
>>>> 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
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>>  Wizard
>>> james at supmenow.com
>>> +44 7523 279 698
>>>
>>
>>
>>
>> --
>>  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/20151216/92199104/attachment.html>

More information about the swift-evolution mailing list