[swift-evolution] Optional Setting
James Campbell
james at supmenow.com
Wed Dec 16 10:50:34 CST 2015
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151216/53e66aee/attachment.html>
More information about the swift-evolution
mailing list