[swift-evolution] Optional Setting

Jordan Rose jordan_rose at apple.com
Tue Dec 15 18:12:52 CST 2015


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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <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>
> 
> 
> 
> 
> -- 
>  Wizard
> james at supmenow.com <mailto:james at supmenow.com>
> +44 7523 279 698 <tel:%2B44%207523%20279%20698>
> 
> 
> 
> -- 
>  Wizard
> james at supmenow.com <mailto:james at supmenow.com>
> +44 7523 279 698
>  _______________________________________________
> 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/20151215/dfd5ad04/attachment.html>


More information about the swift-evolution mailing list