Optional Setting

Evolution Discussion
21

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@swift.org> wrote:

Can you guys give me tips on how to improve this PR
Introduce a optional value setter `??=` by jcampbell05 · Pull Request #63 · apple/swift-evolution · GitHub 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@supmenow.com> > wrote:

On second thoughts, I'm preparing one :)

On Wed, Dec 16, 2015 at 12:24 AM, James Campbell <james@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@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@apple.com> >>>> wrote:

It's possible that @_transparent
<https://github.com/apple/swift/blob/master/docs/TransparentAttr.rst&gt; 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@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@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@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@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
 Wizard
james@supmenow.com
+44 7523 279 698

--
 Wizard
james@supmenow.com
+44 7523 279 698
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
 Wizard
james@supmenow.com
+44 7523 279 698

--
 Wizard
james@supmenow.com
+44 7523 279 698

--
 Wizard
james@supmenow.com
+44 7523 279 698

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

22

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.

Consider using it multiple times with the same variable

    var value = someInitialValue
    value ??= fallback1
    value ??= fallback2

Of course, this could also be "let value = someInitialValue ?? falback1 ??
fallback2", which isn't necessarily more readable, but arguably better
because it uses let.

   - 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.

I think you're right that this is one of the most common cases. Without

this proposal:

    if self.property == nil { self.property = newValue [possibly optional] }
    if let value = self.property {
        // ...
    }

or

    let value: T
    if let v = self.property { value = v }
    else { value = newValue [non-optional]; self.property = value }
    // ...

With this proposal:

    self.property ??= newValue
    if let value = self.property {
        // ...
    }

I think the second is cleaner, but the difference isn't huge. You could
also have ??= return the new value, so you can embed it in a larger
expression/optional-binding, but that's not consistent with any of the
other compound assignment operators.

   - 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 disagree that this would be unexpected. It's consistent with how ??, &&,

and || work. (And now that ++ and -- are going away, it likely matters even
less.)

Anecdotally, I introduced this operator about 4 months ago to a codebase
with ~16,500 lines of Swift. It's been used 4 times.

Jacob

···

On Tue, Dec 15, 2015 at 4:58 PM, Marc Knaup <marc@knaup.koeln> wrote:

23

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.

···

On 16 Dec 2015, at 00:58, Marc Knaup via swift-evolution <swift-evolution@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.

24

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.

···

On Dec 16, 2015, at 4:12 AM, Al Skipp via swift-evolution <swift-evolution@swift.org> wrote:

On 16 Dec 2015, at 00:58, Marc Knaup via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

25

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

···

On Dec 16, 2015, at 6:22 AM, Kevin Wooten via swift-evolution <swift-evolution@swift.org> wrote:

On Dec 16, 2015, at 4:12 AM, Al Skipp via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On 16 Dec 2015, at 00:58, Marc Knaup via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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.

26

I'm still uncertain whether that would solve the issue at the right
location.

How do you end up in such a situation where this is actually necessary?
Why do I not end up in such situations?
I'd like to understand where the discrepancy comes from.

I.e. where do you define chatTitleName? Where else do you set chatTitleName?
Why isn't it initially set to "Default" an then overwritten on-demand?

···

On Wed, Dec 16, 2015 at 3:22 PM, Kevin Wooten <kdubb@me.com> wrote:

On Dec 16, 2015, at 4:12 AM, Al Skipp via swift-evolution < > swift-evolution@swift.org> wrote:

On 16 Dec 2015, at 00:58, Marc Knaup via swift-evolution < > swift-evolution@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.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

27

I've started a formal proposal here:

···

On Wed, Dec 16, 2015 at 4:48 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote:

On Dec 16, 2015, at 6:22 AM, Kevin Wooten via swift-evolution < > swift-evolution@swift.org> wrote:

On Dec 16, 2015, at 4:12 AM, Al Skipp via swift-evolution < > swift-evolution@swift.org> wrote:

On 16 Dec 2015, at 00:58, Marc Knaup via swift-evolution < > swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
 Wizard
james@supmenow.com
+44 7523 279 698

28

While I used `||=` in Ruby all the time, where everything can be `nil`, I've found that Swift's Optional model is different enough that I've never really desired a `??=`, so I'm a -1 for the proposal, as I see it encouraging the use of optionals where a non-optional would be preferred.

With the `chatTitleName` example, I'd probably make `"Default"` the default argument on initialization (and make it so `chatTitleName` is not optional), or I'd move the `chatTitleName ?? "Default"` into the presentation logic.

Well I was using real variable names but the example was contrived; I should have made that clearer. Also, I didn’t mean to sound like I was in clear support of this addition. I was really just putting it into context with regard to variables names where we’ve used “??”.

In reality my vote is.. ±0

···

On Dec 16, 2015, at 8:03 AM, Stephen Celis <stephen.celis@gmail.com> wrote:

Stephen

On Wed, Dec 16, 2015 at 9:28 AM, Marc Knaup via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I'm still uncertain whether that would solve the issue at the right location.

On Wed, Dec 16, 2015 at 3:22 PM, Kevin Wooten <kdubb@me.com <mailto:kdubb@me.com>> wrote:

On Dec 16, 2015, at 4:12 AM, Al Skipp via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On 16 Dec 2015, at 00:58, Marc Knaup via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

29

-1: a big point of ?? operator is the fact that it strips an optional
Also it's really unclear whether didSet is triggered in the "do nothing" case.

It seems the appropriate thing to do in the “do nothing” case is… nothing.

···

On Dec 16, 2015, at 8:19 AM, ilya <ilya.nikokoshev@gmail.com> wrote:

On Wed, Dec 16, 2015 at 18:07 Ian Ynda-Hummel via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
It seems to be that the object property case (which is the most common use of ||= I've seen with Ruby) is mostly solved by the fact that Swift allows you to specify default (or lazy loaded!) values on variable declaration.

    class MessagesViewController: UIViewController {
        var chatTitleName = "Default"
    }

As for the case Jacob mentioned above:

    var value = someInitialValue
    value ??= fallback1
    value ??= fallback2

It seems like that can be written as:

    var value = someInitialValue
        ?? fallback1
        ?? fallback2

Which doesn't seem appreciably different to me, though I am curious what others think about the style. That said, I can imagine more complex cases where it might seem appropriate. Say:

    var value = someInitialValue

    var something
    ...do some processing

    value ??= something
    guard value else { return }

    var somethingElse
    ...do some processing

    value ??= somethingElse
    guard value else { return }

But that can also be rewritten as something like:

    var value = someInitialValue
        ?? {
            var something
            ...do some processing
            return something
        }()
        ?? {
            var somethingElse
            ...do some processing
            return somethingElse
        }()

Again, curious what people think about the style.

On Wed, Dec 16, 2015 at 9:28 AM Marc Knaup via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I'm still uncertain whether that would solve the issue at the right location.

How do you end up in such a situation where this is actually necessary?
Why do I not end up in such situations?
I'd like to understand where the discrepancy comes from.

I.e. where do you define chatTitleName? Where else do you set chatTitleName?
Why isn't it initially set to "Default" an then overwritten on-demand?

On Wed, Dec 16, 2015 at 3:22 PM, Kevin Wooten <kdubb@me.com <mailto:kdubb@me.com>> wrote:

On Dec 16, 2015, at 4:12 AM, Al Skipp via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On 16 Dec 2015, at 00:58, Marc Knaup via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

30

It seems to be that the object property case (which is the most common use of ||= I've seen with Ruby) is mostly solved by the fact that Swift allows you to specify default (or lazy loaded!) values on variable declaration.

    class MessagesViewController: UIViewController {
        var chatTitleName = "Default"
    }

Haha again sorry, I used real names, but a completely contrived example of length.

As for the case Jacob mentioned above:

    var value = someInitialValue
    value ??= fallback1
    value ??= fallback2

It seems like that can be written as:

    var value = someInitialValue
        ?? fallback1
        ?? fallback2

Which doesn't seem appreciably different to me, though I am curious what others think about the style. That said, I can imagine more complex cases where it might seem appropriate. Say:

    var value = someInitialValue

    var something
    ...do some processing

    value ??= something
    guard value else { return }

    var somethingElse
    ...do some processing

    value ??= somethingElse
    guard value else { return }

But that can also be rewritten as something like:

    var value = someInitialValue
        ?? {
            var something
            ...do some processing
            return something
        }()
        ?? {
            var somethingElse
            ...do some processing
            return somethingElse
        }()

I realize you are not endorsing either of these styles but the form using “??” smacks of trying to cram as much code as possible into the fewest characters. As we know that isn’t a goal of swift. Even, if the “??=“ existed I would probably rework this code into it’s long form with normal if statements for clarity.

···

On Dec 16, 2015, at 8:07 AM, Ian Ynda-Hummel <ianynda@gmail.com> wrote:

Again, curious what people think about the style.

On Wed, Dec 16, 2015 at 9:28 AM Marc Knaup via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I'm still uncertain whether that would solve the issue at the right location.

How do you end up in such a situation where this is actually necessary?
Why do I not end up in such situations?
I'd like to understand where the discrepancy comes from.

I.e. where do you define chatTitleName? Where else do you set chatTitleName?
Why isn't it initially set to "Default" an then overwritten on-demand?

On Wed, Dec 16, 2015 at 3:22 PM, Kevin Wooten <kdubb@me.com <mailto:kdubb@me.com>> wrote:

On Dec 16, 2015, at 4:12 AM, Al Skipp via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On 16 Dec 2015, at 00:58, Marc Knaup via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

31

While I used `||=` in Ruby all the time, where everything can be `nil`,
I've found that Swift's Optional model is different enough that I've never
really desired a `??=`, so I'm a -1 for the proposal, as I see it
encouraging the use of optionals where a non-optional would be preferred.

With the `chatTitleName` example, I'd probably make `"Default"` the default
argument on initialization (and make it so `chatTitleName` is not
optional), or I'd move the `chatTitleName ?? "Default"` into the
presentation logic.

Stephen

···

On Wed, Dec 16, 2015 at 9:28 AM, Marc Knaup via swift-evolution < swift-evolution@swift.org> wrote:

I'm still uncertain whether that would solve the issue at the right
location.

How do you end up in such a situation where this is actually necessary?
Why do I not end up in such situations?
I'd like to understand where the discrepancy comes from.

I.e. where do you define chatTitleName? Where else do you set
chatTitleName?
Why isn't it initially set to "Default" an then overwritten on-demand?

On Wed, Dec 16, 2015 at 3:22 PM, Kevin Wooten <kdubb@me.com> wrote:

On Dec 16, 2015, at 4:12 AM, Al Skipp via swift-evolution < >> swift-evolution@swift.org> wrote:

On 16 Dec 2015, at 00:58, Marc Knaup via swift-evolution < >> swift-evolution@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.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

32

It seems to be that the object property case (which is the most common use
of ||= I've seen with Ruby) is mostly solved by the fact that Swift allows
you to specify default (or lazy loaded!) values on variable declaration.

    class MessagesViewController: UIViewController {
        var chatTitleName = "Default"
    }

As for the case Jacob mentioned above:

    var value = someInitialValue
    value ??= fallback1
    value ??= fallback2

It seems like that can be written as:

    var value = someInitialValue
        ?? fallback1
        ?? fallback2

Which doesn't seem appreciably different to me, though I am curious what
others think about the style. That said, I can imagine more complex cases
where it might seem appropriate. Say:

    var value = someInitialValue

    var something
    ...do some processing

    value ??= something
    guard value else { return }

    var somethingElse
    ...do some processing

    value ??= somethingElse
    guard value else { return }

But that can also be rewritten as something like:

    var value = someInitialValue
        ?? {
            var something
            ...do some processing
            return something
        }()
        ?? {
            var somethingElse
            ...do some processing
            return somethingElse
        }()

Again, curious what people think about the style.

···

On Wed, Dec 16, 2015 at 9:28 AM Marc Knaup via swift-evolution < swift-evolution@swift.org> wrote:

I'm still uncertain whether that would solve the issue at the right
location.

How do you end up in such a situation where this is actually necessary?
Why do I not end up in such situations?
I'd like to understand where the discrepancy comes from.

I.e. where do you define chatTitleName? Where else do you set
chatTitleName?
Why isn't it initially set to "Default" an then overwritten on-demand?

On Wed, Dec 16, 2015 at 3:22 PM, Kevin Wooten <kdubb@me.com> wrote:

On Dec 16, 2015, at 4:12 AM, Al Skipp via swift-evolution < >> swift-evolution@swift.org> wrote:

On 16 Dec 2015, at 00:58, Marc Knaup via swift-evolution < >> swift-evolution@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.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

33

-1: a big point of ?? operator is the fact that it strips an optional
Also it's really unclear whether didSet is triggered in the "do nothing"
case.

···

On Wed, Dec 16, 2015 at 18:07 Ian Ynda-Hummel via swift-evolution < swift-evolution@swift.org> wrote:

It seems to be that the object property case (which is the most common use
of ||= I've seen with Ruby) is mostly solved by the fact that Swift allows
you to specify default (or lazy loaded!) values on variable declaration.

    class MessagesViewController: UIViewController {
        var chatTitleName = "Default"
    }

As for the case Jacob mentioned above:

    var value = someInitialValue
    value ??= fallback1
    value ??= fallback2

It seems like that can be written as:

    var value = someInitialValue
        ?? fallback1
        ?? fallback2

Which doesn't seem appreciably different to me, though I am curious what
others think about the style. That said, I can imagine more complex cases
where it might seem appropriate. Say:

    var value = someInitialValue

    var something
    ...do some processing

    value ??= something
    guard value else { return }

    var somethingElse
    ...do some processing

    value ??= somethingElse
    guard value else { return }

But that can also be rewritten as something like:

    var value = someInitialValue
        ?? {
            var something
            ...do some processing
            return something
        }()
        ?? {
            var somethingElse
            ...do some processing
            return somethingElse
        }()

Again, curious what people think about the style.

On Wed, Dec 16, 2015 at 9:28 AM Marc Knaup via swift-evolution < > swift-evolution@swift.org> wrote:

I'm still uncertain whether that would solve the issue at the right
location.

How do you end up in such a situation where this is actually necessary?
Why do I not end up in such situations?
I'd like to understand where the discrepancy comes from.

I.e. where do you define chatTitleName? Where else do you set
chatTitleName?
Why isn't it initially set to "Default" an then overwritten on-demand?

On Wed, Dec 16, 2015 at 3:22 PM, Kevin Wooten <kdubb@me.com> wrote:

On Dec 16, 2015, at 4:12 AM, Al Skipp via swift-evolution < >>> swift-evolution@swift.org> wrote:

On 16 Dec 2015, at 00:58, Marc Knaup via swift-evolution < >>> swift-evolution@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.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

34

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@swift.org> wrote:

I've started a formal proposal here:

Introduce a optional value setter `??=` by jcampbell05 · Pull Request #63 · apple/swift-evolution · GitHub

On Wed, Dec 16, 2015 at 4:48 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote:

On Dec 16, 2015, at 6:22 AM, Kevin Wooten via swift-evolution < >> swift-evolution@swift.org> wrote:

On Dec 16, 2015, at 4:12 AM, Al Skipp via swift-evolution < >> swift-evolution@swift.org> wrote:

On 16 Dec 2015, at 00:58, Marc Knaup via swift-evolution < >> swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
 Wizard
james@supmenow.com
+44 7523 279 698
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Javier Soto

35

An Optional cannot be stripped from a property which is likely to be the most common use for it. I am pretty ambivalent about this proposal but don’t think the inability to strip a level of Optional is a sound argument against it.

···

On Dec 16, 2015, at 9:19 AM, ilya via swift-evolution <swift-evolution@swift.org> wrote:

-1: a big point of ?? operator is the fact that it strips an optional
Also it's really unclear whether didSet is triggered in the "do nothing" case.
On Wed, Dec 16, 2015 at 18:07 Ian Ynda-Hummel via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
It seems to be that the object property case (which is the most common use of ||= I've seen with Ruby) is mostly solved by the fact that Swift allows you to specify default (or lazy loaded!) values on variable declaration.

    class MessagesViewController: UIViewController {
        var chatTitleName = "Default"
    }

As for the case Jacob mentioned above:

    var value = someInitialValue
    value ??= fallback1
    value ??= fallback2

It seems like that can be written as:

    var value = someInitialValue
        ?? fallback1
        ?? fallback2

Which doesn't seem appreciably different to me, though I am curious what others think about the style. That said, I can imagine more complex cases where it might seem appropriate. Say:

    var value = someInitialValue

    var something
    ...do some processing

    value ??= something
    guard value else { return }

    var somethingElse
    ...do some processing

    value ??= somethingElse
    guard value else { return }

But that can also be rewritten as something like:

    var value = someInitialValue
        ?? {
            var something
            ...do some processing
            return something
        }()
        ?? {
            var somethingElse
            ...do some processing
            return somethingElse
        }()

Again, curious what people think about the style.

On Wed, Dec 16, 2015 at 9:28 AM Marc Knaup via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I'm still uncertain whether that would solve the issue at the right location.

How do you end up in such a situation where this is actually necessary?
Why do I not end up in such situations?
I'd like to understand where the discrepancy comes from.

I.e. where do you define chatTitleName? Where else do you set chatTitleName?
Why isn't it initially set to "Default" an then overwritten on-demand?

On Wed, Dec 16, 2015 at 3:22 PM, Kevin Wooten <kdubb@me.com <mailto:kdubb@me.com>> wrote:

On Dec 16, 2015, at 4:12 AM, Al Skipp via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On 16 Dec 2015, at 00:58, Marc Knaup via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

36

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@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@swift.org> wrote:

I've started a formal proposal here:

Introduce a optional value setter `??=` by jcampbell05 · Pull Request #63 · apple/swift-evolution · GitHub

On Wed, Dec 16, 2015 at 4:48 PM, Dave Abrahams via swift-evolution < >> swift-evolution@swift.org> wrote:

On Dec 16, 2015, at 6:22 AM, Kevin Wooten via swift-evolution < >>> swift-evolution@swift.org> wrote:

On Dec 16, 2015, at 4:12 AM, Al Skipp via swift-evolution < >>> swift-evolution@swift.org> wrote:

On 16 Dec 2015, at 00:58, Marc Knaup via swift-evolution < >>> swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
 Wizard
james@supmenow.com
+44 7523 279 698
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Javier Soto
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

37

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@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@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@swift.org> wrote:

I've started a formal proposal here:

Introduce a optional value setter `??=` by jcampbell05 · Pull Request #63 · apple/swift-evolution · GitHub

On Wed, Dec 16, 2015 at 4:48 PM, Dave Abrahams via swift-evolution < >>> swift-evolution@swift.org> wrote:

On Dec 16, 2015, at 6:22 AM, Kevin Wooten via swift-evolution < >>>> swift-evolution@swift.org> wrote:

On Dec 16, 2015, at 4:12 AM, Al Skipp via swift-evolution < >>>> swift-evolution@swift.org> wrote:

On 16 Dec 2015, at 00:58, Marc Knaup via swift-evolution < >>>> swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
 Wizard
james@supmenow.com
+44 7523 279 698
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Javier Soto
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

38

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

Seems like a distraction to me, FWIW.

Jacob Bandes-Storch

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.

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.

I've started a formal proposal here:

Introduce a optional value setter `??=` by jcampbell05 · Pull Request #63 · apple/swift-evolution · GitHub

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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
 Wizard
james@supmenow.com <mailto:james@supmenow.com>
+44 7523 279 698 <tel:%2B44%207523%20279%20698> _______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
--
Javier Soto
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

-Dave

···

On Dec 16, 2015, at 2:07 PM, Jacob Bandes-Storch via swift-evolution <swift-evolution@swift.org> wrote:
On Wed, Dec 16, 2015 at 2:04 PM, Marc Knaup via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Wed, Dec 16, 2015 at 10:58 PM, Javier Soto via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Wed, Dec 16, 2015 at 8:50 AM James Campbell via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Wed, Dec 16, 2015 at 4:48 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Dec 16, 2015, at 6:22 AM, Kevin Wooten via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Dec 16, 2015, at 4:12 AM, Al Skipp via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On 16 Dec 2015, at 00:58, Marc Knaup via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: