1

I’d like to propose a new operator for optional assignment in Swift.

The idea is that by using this operator (e.g. by doing a ?= b), the optional on the right would be assigned to the variable on the left only when it has something to assign (i.e. when it's not nil).

The implementation could be something as follows:

/// Optional Assignment Operator
infix operator ?=: AssignmentPrecedence

func ?=<T>(left: inout T, right: T?) {
    if right != nil {
        left = right!
    }
}

func ?=<T>(left: inout T?, right: T?) {
    if right != nil {
        left = right
    }
}

I hope you will consider adding this on a future release of this great programming language.

Kind regards,
N. S.

2

I’d like to propose a new operator for optional assignment in Swift.

The idea is that by using this operator (e.g. by doing a ?= b), the optional on the right would be assigned to the variable on the left only when it has something to assign (i.e. when it's not nil).

`a? = b` already does this. Maybe we need a fixit to make that more apparent, though.

-Joe

···

On Jan 25, 2017, at 8:40 AM, Nichi Shin via swift-evolution <swift-evolution@swift.org> wrote:

The implementation could be something as follows:

/// Optional Assignment Operator
infix operator ?=: AssignmentPrecedence

func ?=<T>(left: inout T, right: T?) {
    if right != nil {
        left = right!
    }
}

func ?=<T>(left: inout T?, right: T?) {
    if right != nil {
        left = right
    }
}

I hope you will consider adding this on a future release of this great programming language.

Kind regards,
N. S.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

3

I think this is the same proposal as this rejected proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0024-optional-value-setter.md

···

Le 25 janv. 2017 à 08:56, Sean Heber via swift-evolution <swift-evolution@swift.org> a écrit :

Seems trivial to do this now:

var foo = someOptional ?? foo

Unless I’m not understanding?

l8r
Sean

On Jan 25, 2017, at 10:40 AM, Nichi Shin via swift-evolution <swift-evolution@swift.org> wrote:

I’d like to propose a new operator for optional assignment in Swift.

The idea is that by using this operator (e.g. by doing a ?= b), the optional on the right would be assigned to the variable on the left only when it has something to assign (i.e. when it's not nil).

The implementation could be something as follows:

/// Optional Assignment Operator
infix operator ?=: AssignmentPrecedence

func ?=<T>(left: inout T, right: T?) {
   if right != nil {
       left = right!
   }
}

func ?=<T>(left: inout T?, right: T?) {
   if right != nil {
       left = right
   }
}

I hope you will consider adding this on a future release of this great programming language.

Kind regards,
N. S.
_______________________________________________
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

4

Seems trivial to do this now:

var foo = someOptional ?? foo

Unless I’m not understanding?

l8r
Sean

···

On Jan 25, 2017, at 10:40 AM, Nichi Shin via swift-evolution <swift-evolution@swift.org> wrote:

I’d like to propose a new operator for optional assignment in Swift.

The idea is that by using this operator (e.g. by doing a ?= b), the optional on the right would be assigned to the variable on the left only when it has something to assign (i.e. when it's not nil).

The implementation could be something as follows:

/// Optional Assignment Operator
infix operator ?=: AssignmentPrecedence

func ?=<T>(left: inout T, right: T?) {
    if right != nil {
        left = right!
    }
}

func ?=<T>(left: inout T?, right: T?) {
    if right != nil {
        left = right
    }
}

I hope you will consider adding this on a future release of this great programming language.

Kind regards,
N. S.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

5

Really? My observation from a quick test is that "a? = b" assigns b to a if
a already has a value, or does nothing if it's nil. This is sort of the
opposite of what's being proposed, which is that "a ?= b" should assign to
a only if it does NOT have a value.

···

On Wed, Jan 25, 2017 at 9:33 AM Joe Groff via swift-evolution < swift-evolution@swift.org> wrote:

> On Jan 25, 2017, at 8:40 AM, Nichi Shin via swift-evolution < > swift-evolution@swift.org> wrote:
>
> I’d like to propose a new operator for optional assignment in Swift.
>
> The idea is that by using this operator (e.g. by doing a ?= b), the
optional on the right would be assigned to the variable on the left only
when it has something to assign (i.e. when it's not nil).

`a? = b` already does this. Maybe we need a fixit to make that more
apparent, though.

-Joe

>
> The implementation could be something as follows:
>
> /// Optional Assignment Operator
> infix operator ?=: AssignmentPrecedence
>
> func ?=<T>(left: inout T, right: T?) {
> if right != nil {
> left = right!
> }
> }
>
> func ?=<T>(left: inout T?, right: T?) {
> if right != nil {
> left = right
> }
> }
>
> I hope you will consider adding this on a future release of this great
programming language.
>
> Kind regards,
> N. S.
> _______________________________________________
> 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

6

My mistake, I misread the proposal. What Nichi appears to be suggesting is an assignment that only happens when `b` has a value. I would hesitate to spell that `?=` since that's so similar to '? =', but perhaps it's useful, though there are many ways to spell that already.

-Joe

···

On Jan 25, 2017, at 9:47 AM, Jacob Bandes-Storch <jtbandes@gmail.com> wrote:

Really? My observation from a quick test is that "a? = b" assigns b to a if a already has a value, or does nothing if it's nil. This is sort of the opposite of what's being proposed, which is that "a ?= b" should assign to a only if it does NOT have a value.

7

Interesting, I think I misread it too. The one I was thinking of is the
same as the rejected proposal:

Jacob

···

On Wed, Jan 25, 2017 at 10:11 AM, Joe Groff <jgroff@apple.com> wrote:

> On Jan 25, 2017, at 9:47 AM, Jacob Bandes-Storch <jtbandes@gmail.com> > wrote:
>
> Really? My observation from a quick test is that "a? = b" assigns b to a
if a already has a value, or does nothing if it's nil. This is sort of the
opposite of what's being proposed, which is that "a ?= b" should assign to
a only if it does NOT have a value.

My mistake, I misread the proposal. What Nichi appears to be suggesting is
an assignment that only happens when `b` has a value. I would hesitate to
spell that `?=` since that's so similar to '? =', but perhaps it's useful,
though there are many ways to spell that already.

-Joe

8

Agreed, IMO it would be quite dangerous for "a ??= b" to mean anything
other than "a = a ?? b".

On another note, I don't see the value of "a? = b". I had never realized
before that this works. Is this feature actually used in the wild? Should
we consider removing it? (I could perhaps see some value if the assignment
operator were overloadable, but it's not.)

Jacob

···

On Wed, Jan 25, 2017 at 10:28 AM, John McCall <rjmccall@apple.com> wrote:

On Jan 25, 2017, at 12:47 PM, Jacob Bandes-Storch via swift-evolution < > swift-evolution@swift.org> wrote:
Really? My observation from a quick test is that "a? = b" assigns b to a
if a already has a value, or does nothing if it's nil. This is sort of the
opposite of what's being proposed, which is that "a ?= b" should assign to
a only if it does NOT have a value.

Right. On the other hand, this does seem like a poor spelling for the
operator, given the ease of confusion.

Also, I'm finding it hard to imagine a use for this where the equivalent
?? invocation wouldn't be *much* clearer. It just feels like you must be
doing something backwards — "I've filled in a default value for this
variable, now overwrite it if this other value exists". Wouldn't the
reverse generally be better?

John.

On Wed, Jan 25, 2017 at 9:33 AM Joe Groff via swift-evolution < > swift-evolution@swift.org> wrote:

> On Jan 25, 2017, at 8:40 AM, Nichi Shin via swift-evolution < >> swift-evolution@swift.org> wrote:
>
> I’d like to propose a new operator for optional assignment in Swift.
>
> The idea is that by using this operator (e.g. by doing a ?= b), the
optional on the right would be assigned to the variable on the left only
when it has something to assign (i.e. when it's not nil).

`a? = b` already does this. Maybe we need a fixit to make that more
apparent, though.

-Joe

>
> The implementation could be something as follows:
>
> /// Optional Assignment Operator
> infix operator ?=: AssignmentPrecedence
>
> func ?=<T>(left: inout T, right: T?) {
> if right != nil {
> left = right!
> }
> }
>
> func ?=<T>(left: inout T?, right: T?) {
> if right != nil {
> left = right
> }
> }
>
> I hope you will consider adding this on a future release of this great
programming language.
>
> Kind regards,
> N. S.
> _______________________________________________
> 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

9

-1

I personally think Optional has received too much special treatment in the language already. I’ve known folks who have written Swift professionally for almost a year until they realize Optional is just an enum. More magic syntax around it would only make this worse.

···

On Jan 25, 2017, at 10:35 AM, Jacob Bandes-Storch via swift-evolution <swift-evolution@swift.org> wrote:

Agreed, IMO it would be quite dangerous for "a ??= b" to mean anything other than "a = a ?? b".

On another note, I don't see the value of "a? = b". I had never realized before that this works. Is this feature actually used in the wild? Should we consider removing it? (I could perhaps see some value if the assignment operator were overloadable, but it's not.)

Jacob

On Wed, Jan 25, 2017 at 10:28 AM, John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>> wrote:

On Jan 25, 2017, at 12:47 PM, Jacob Bandes-Storch via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Really? My observation from a quick test is that "a? = b" assigns b to a if a already has a value, or does nothing if it's nil. This is sort of the opposite of what's being proposed, which is that "a ?= b" should assign to a only if it does NOT have a value.

Right. On the other hand, this does seem like a poor spelling for the operator, given the ease of confusion.

Also, I'm finding it hard to imagine a use for this where the equivalent ?? invocation wouldn't be *much* clearer. It just feels like you must be doing something backwards — "I've filled in a default value for this variable, now overwrite it if this other value exists". Wouldn't the reverse generally be better?

John.

On Wed, Jan 25, 2017 at 9:33 AM Joe Groff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

> On Jan 25, 2017, at 8:40 AM, Nichi Shin via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
> I’d like to propose a new operator for optional assignment in Swift.
>
> The idea is that by using this operator (e.g. by doing a ?= b), the optional on the right would be assigned to the variable on the left only when it has something to assign (i.e. when it's not nil).

`a? = b` already does this. Maybe we need a fixit to make that more apparent, though.

-Joe

>
> The implementation could be something as follows:
>
> /// Optional Assignment Operator
> infix operator ?=: AssignmentPrecedence
>
> func ?=<T>(left: inout T, right: T?) {
> if right != nil {
> left = right!
> }
> }
>
> func ?=<T>(left: inout T?, right: T?) {
> if right != nil {
> left = right
> }
> }
>
> I hope you will consider adding this on a future release of this great programming language.
>
> Kind regards,
> N. S.
> _______________________________________________
> 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

10

Really? My observation from a quick test is that "a? = b" assigns b to a if a already has a value, or does nothing if it's nil. This is sort of the opposite of what's being proposed, which is that "a ?= b" should assign to a only if it does NOT have a value.

Right. On the other hand, this does seem like a poor spelling for the operator, given the ease of confusion.

Also, I'm finding it hard to imagine a use for this where the equivalent ?? invocation wouldn't be *much* clearer. It just feels like you must be doing something backwards — "I've filled in a default value for this variable, now overwrite it if this other value exists". Wouldn't the reverse generally be better?

John.

···

On Jan 25, 2017, at 12:47 PM, Jacob Bandes-Storch via swift-evolution <swift-evolution@swift.org> wrote:

On Wed, Jan 25, 2017 at 9:33 AM Joe Groff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

> On Jan 25, 2017, at 8:40 AM, Nichi Shin via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
> I’d like to propose a new operator for optional assignment in Swift.
>
> The idea is that by using this operator (e.g. by doing a ?= b), the optional on the right would be assigned to the variable on the left only when it has something to assign (i.e. when it's not nil).

`a? = b` already does this. Maybe we need a fixit to make that more apparent, though.

-Joe

>
> The implementation could be something as follows:
>
> /// Optional Assignment Operator
> infix operator ?=: AssignmentPrecedence
>
> func ?=<T>(left: inout T, right: T?) {
> if right != nil {
> left = right!
> }
> }
>
> func ?=<T>(left: inout T?, right: T?) {
> if right != nil {
> left = right
> }
> }
>
> I hope you will consider adding this on a future release of this great programming language.
>
> Kind regards,
> N. S.
> _______________________________________________
> 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

11

Agreed, IMO it would be quite dangerous for "a ??= b" to mean anything other than "a = a ?? b".

On another note, I don't see the value of "a? = b". I had never realized before that this works. Is this feature actually used in the wild? Should we consider removing it? (I could perhaps see some value if the assignment operator were overloadable, but it's not.)

The core semantics (that ? on an l-value still produces an l-value) fall out from the ability to call a mutating method with a?.foo(). Once you have that, you have to decide what it means to put such an l-value to the left of an assignment operator, and we decided to make it Just Work™. I agree that it is not a particularly useful operation in idiomatic Swift, especially with simple assignment (=), and we could consider just disallowing it.

It also comes up with optional properties, I think, which is something we weren't always certain we were going to ban in native Swift (as opposed to imported ObjC code, where they're a fact of life).

John.

···

On Jan 25, 2017, at 1:35 PM, Jacob Bandes-Storch <jtbandes@gmail.com> wrote:

Jacob

On Wed, Jan 25, 2017 at 10:28 AM, John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>> wrote:

On Jan 25, 2017, at 12:47 PM, Jacob Bandes-Storch via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Really? My observation from a quick test is that "a? = b" assigns b to a if a already has a value, or does nothing if it's nil. This is sort of the opposite of what's being proposed, which is that "a ?= b" should assign to a only if it does NOT have a value.

Right. On the other hand, this does seem like a poor spelling for the operator, given the ease of confusion.

Also, I'm finding it hard to imagine a use for this where the equivalent ?? invocation wouldn't be *much* clearer. It just feels like you must be doing something backwards — "I've filled in a default value for this variable, now overwrite it if this other value exists". Wouldn't the reverse generally be better?

John.

On Wed, Jan 25, 2017 at 9:33 AM Joe Groff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

> On Jan 25, 2017, at 8:40 AM, Nichi Shin via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
> I’d like to propose a new operator for optional assignment in Swift.
>
> The idea is that by using this operator (e.g. by doing a ?= b), the optional on the right would be assigned to the variable on the left only when it has something to assign (i.e. when it's not nil).

`a? = b` already does this. Maybe we need a fixit to make that more apparent, though.

-Joe

>
> The implementation could be something as follows:
>
> /// Optional Assignment Operator
> infix operator ?=: AssignmentPrecedence
>
> func ?=<T>(left: inout T, right: T?) {
> if right != nil {
> left = right!
> }
> }
>
> func ?=<T>(left: inout T?, right: T?) {
> if right != nil {
> left = right
> }
> }
>
> I hope you will consider adding this on a future release of this great programming language.
>
> Kind regards,
> N. S.
> _______________________________________________
> 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

12

-1

···

On Wed, Jan 25, 2017 at 1:11 PM Joe Groff via swift-evolution < swift-evolution@swift.org> wrote:

> On Jan 25, 2017, at 9:47 AM, Jacob Bandes-Storch <jtbandes@gmail.com> > wrote:
>
> Really? My observation from a quick test is that "a? = b" assigns b to a
if a already has a value, or does nothing if it's nil. This is sort of the
opposite of what's being proposed, which is that "a ?= b" should assign to
a only if it does NOT have a value.

My mistake, I misread the proposal. What Nichi appears to be suggesting is
an assignment that only happens when `b` has a value. I would hesitate to
spell that `?=` since that's so similar to '? =', but perhaps it's useful,
though there are many ways to spell that already.

-Joe

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

13

Given lack of evidence of harm, is it really important to make such a
source-breaking change?

···

On Wed, Jan 25, 2017 at 12:45 John McCall via swift-evolution < swift-evolution@swift.org> wrote:

On Jan 25, 2017, at 1:35 PM, Jacob Bandes-Storch <jtbandes@gmail.com> > wrote:

Agreed, IMO it would be quite dangerous for "a ??= b" to mean anything
other than "a = a ?? b".

On another note, I don't see the value of "a? = b". I had never realized
before that this works. Is this feature actually used in the wild? Should
we consider removing it? (I could perhaps see some value if the assignment
operator were overloadable, but it's not.)

The core semantics (that ? on an l-value still produces an l-value) fall
out from the ability to call a mutating method with a?.foo(). Once you
have that, you have to decide what it means to put such an l-value to the
left of an assignment operator, and we decided to make it Just Work™. I
agree that it is not a particularly useful operation in idiomatic Swift,
especially with simple assignment (=), and we could consider just
disallowing it.

It also comes up with optional properties, I think, which is something we
weren't always certain we were going to ban in native Swift (as opposed to
imported ObjC code, where they're a fact of life).

John.

Jacob

On Wed, Jan 25, 2017 at 10:28 AM, John McCall <rjmccall@apple.com> wrote:

On Jan 25, 2017, at 12:47 PM, Jacob Bandes-Storch via swift-evolution < > swift-evolution@swift.org> wrote:
Really? My observation from a quick test is that "a? = b" assigns b to a
if a already has a value, or does nothing if it's nil. This is sort of the
opposite of what's being proposed, which is that "a ?= b" should assign to
a only if it does NOT have a value.

Right. On the other hand, this does seem like a poor spelling for the
operator, given the ease of confusion.

Also, I'm finding it hard to imagine a use for this where the equivalent
?? invocation wouldn't be *much* clearer. It just feels like you must be
doing something backwards — "I've filled in a default value for this
variable, now overwrite it if this other value exists". Wouldn't the
reverse generally be better?

John.

On Wed, Jan 25, 2017 at 9:33 AM Joe Groff via swift-evolution < > swift-evolution@swift.org> wrote:

> On Jan 25, 2017, at 8:40 AM, Nichi Shin via swift-evolution < > swift-evolution@swift.org> wrote:
>
> I’d like to propose a new operator for optional assignment in Swift.
>
> The idea is that by using this operator (e.g. by doing a ?= b), the
optional on the right would be assigned to the variable on the left only
when it has something to assign (i.e. when it's not nil).

`a? = b` already does this. Maybe we need a fixit to make that more
apparent, though.

-Joe

>
> The implementation could be something as follows:
>
> /// Optional Assignment Operator
> infix operator ?=: AssignmentPrecedence
>
> func ?=<T>(left: inout T, right: T?) {
> if right != nil {
> left = right!
> }
> }
>
> func ?=<T>(left: inout T?, right: T?) {
> if right != nil {
> left = right
> }
> }
>
> I hope you will consider adding this on a future release of this great
programming language.
>
> Kind regards,
> N. S.
> _______________________________________________
> 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

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

14

Given lack of evidence of harm, is it really important to make such a source-breaking change?

My first instinct is that, no, it's not important. However, we haven't actually *tried* to find any evidence of harm, so it's a bit conclusory. If someone wants to make an evidence-based argument that it's harmful and that almost nobody is using it (intentionally/correctly), the balance could swing the other way. That's for someone else to prove, though, since yes, at this point the bias has to be towards leaving things be.

John.

···

On Jan 25, 2017, at 1:48 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Wed, Jan 25, 2017 at 12:45 John McCall via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jan 25, 2017, at 1:35 PM, Jacob Bandes-Storch <jtbandes@gmail.com <mailto:jtbandes@gmail.com>> wrote:

Agreed, IMO it would be quite dangerous for "a ??= b" to mean anything other than "a = a ?? b".

On another note, I don't see the value of "a? = b". I had never realized before that this works. Is this feature actually used in the wild? Should we consider removing it? (I could perhaps see some value if the assignment operator were overloadable, but it's not.)

The core semantics (that ? on an l-value still produces an l-value) fall out from the ability to call a mutating method with a?.foo(). Once you have that, you have to decide what it means to put such an l-value to the left of an assignment operator, and we decided to make it Just Work™. I agree that it is not a particularly useful operation in idiomatic Swift, especially with simple assignment (=), and we could consider just disallowing it.

It also comes up with optional properties, I think, which is something we weren't always certain we were going to ban in native Swift (as opposed to imported ObjC code, where they're a fact of life).

John.

Jacob

On Wed, Jan 25, 2017 at 10:28 AM, John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>> wrote:

On Jan 25, 2017, at 12:47 PM, Jacob Bandes-Storch via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Really? My observation from a quick test is that "a? = b" assigns b to a if a already has a value, or does nothing if it's nil. This is sort of the opposite of what's being proposed, which is that "a ?= b" should assign to a only if it does NOT have a value.

Right. On the other hand, this does seem like a poor spelling for the operator, given the ease of confusion.

Also, I'm finding it hard to imagine a use for this where the equivalent ?? invocation wouldn't be *much* clearer. It just feels like you must be doing something backwards — "I've filled in a default value for this variable, now overwrite it if this other value exists". Wouldn't the reverse generally be better?

John.

On Wed, Jan 25, 2017 at 9:33 AM Joe Groff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

> On Jan 25, 2017, at 8:40 AM, Nichi Shin via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
> I’d like to propose a new operator for optional assignment in Swift.
>
> The idea is that by using this operator (e.g. by doing a ?= b), the optional on the right would be assigned to the variable on the left only when it has something to assign (i.e. when it's not nil).

`a? = b` already does this. Maybe we need a fixit to make that more apparent, though.

-Joe

>
> The implementation could be something as follows:
>
> /// Optional Assignment Operator
> infix operator ?=: AssignmentPrecedence
>
> func ?=<T>(left: inout T, right: T?) {
> if right != nil {
> left = right!
> }
> }
>
> func ?=<T>(left: inout T?, right: T?) {
> if right != nil {
> left = right
> }
> }
>
> I hope you will consider adding this on a future release of this great programming language.
>
> Kind regards,
> N. S.
> _______________________________________________
> 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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

15

If no uses are found (which I suspect will be the case), it becomes hard to
also find evidence of harm other than in contrived scenarios. Perhaps
contrived will be all we can find. Anyway, this is a bit off-topic for this
thread...

···

On Wed, Jan 25, 2017 at 11:24 AM John McCall <rjmccall@apple.com> wrote:

On Jan 25, 2017, at 1:48 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
Given lack of evidence of harm, is it really important to make such a
source-breaking change?

My first instinct is that, no, it's not important. However, we haven't
actually *tried* to find any evidence of harm, so it's a bit conclusory.
If someone wants to make an evidence-based argument that it's harmful and
that almost nobody is using it (intentionally/correctly), the balance could
swing the other way. That's for someone else to prove, though, since yes,
at this point the bias has to be towards leaving things be.

John.

On Wed, Jan 25, 2017 at 12:45 John McCall via swift-evolution < > swift-evolution@swift.org> wrote:

On Jan 25, 2017, at 1:35 PM, Jacob Bandes-Storch <jtbandes@gmail.com> > wrote:

Agreed, IMO it would be quite dangerous for "a ??= b" to mean anything
other than "a = a ?? b".

On another note, I don't see the value of "a? = b". I had never realized
before that this works. Is this feature actually used in the wild? Should
we consider removing it? (I could perhaps see some value if the assignment
operator were overloadable, but it's not.)

The core semantics (that ? on an l-value still produces an l-value) fall
out from the ability to call a mutating method with a?.foo(). Once you
have that, you have to decide what it means to put such an l-value to the
left of an assignment operator, and we decided to make it Just Work™. I
agree that it is not a particularly useful operation in idiomatic Swift,
especially with simple assignment (=), and we could consider just
disallowing it.

It also comes up with optional properties, I think, which is something we
weren't always certain we were going to ban in native Swift (as opposed to
imported ObjC code, where they're a fact of life).

John.

Jacob

On Wed, Jan 25, 2017 at 10:28 AM, John McCall <rjmccall@apple.com> wrote:

On Jan 25, 2017, at 12:47 PM, Jacob Bandes-Storch via swift-evolution < > swift-evolution@swift.org> wrote:
Really? My observation from a quick test is that "a? = b" assigns b to a
if a already has a value, or does nothing if it's nil. This is sort of the
opposite of what's being proposed, which is that "a ?= b" should assign to
a only if it does NOT have a value.

Right. On the other hand, this does seem like a poor spelling for the
operator, given the ease of confusion.

Also, I'm finding it hard to imagine a use for this where the equivalent
?? invocation wouldn't be *much* clearer. It just feels like you must be
doing something backwards — "I've filled in a default value for this
variable, now overwrite it if this other value exists". Wouldn't the
reverse generally be better?

John.

On Wed, Jan 25, 2017 at 9:33 AM Joe Groff via swift-evolution < > swift-evolution@swift.org> wrote:

> On Jan 25, 2017, at 8:40 AM, Nichi Shin via swift-evolution < > swift-evolution@swift.org> wrote:
>
> I’d like to propose a new operator for optional assignment in Swift.
>
> The idea is that by using this operator (e.g. by doing a ?= b), the
optional on the right would be assigned to the variable on the left only
when it has something to assign (i.e. when it's not nil).

`a? = b` already does this. Maybe we need a fixit to make that more
apparent, though.

-Joe

>
> The implementation could be something as follows:
>
> /// Optional Assignment Operator
> infix operator ?=: AssignmentPrecedence
>
> func ?=<T>(left: inout T, right: T?) {
> if right != nil {
> left = right!
> }
> }
>
> func ?=<T>(left: inout T?, right: T?) {
> if right != nil {
> left = right
> }
> }
>
> I hope you will consider adding this on a future release of this great
programming language.
>
> Kind regards,
> N. S.
> _______________________________________________
> 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

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

16

If no uses are found (which I suspect will be the case), it becomes hard to also find evidence of harm other than in contrived scenarios. Perhaps contrived will be all we can find.

Well, if there's no harm, having a weird corner case that doesn't hurt anybody is fine. I certainly suspect that there are use cases for using a non-simple assignment operator there, so calling out = as a special case is a bit weird.

John.

···

On Jan 25, 2017, at 2:37 PM, Jacob Bandes-Storch <jtbandes@gmail.com> wrote:

Anyway, this is a bit off-topic for this thread...
On Wed, Jan 25, 2017 at 11:24 AM John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>> wrote:

On Jan 25, 2017, at 1:48 PM, Xiaodi Wu <xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com>> wrote:
Given lack of evidence of harm, is it really important to make such a source-breaking change?

My first instinct is that, no, it's not important. However, we haven't actually *tried* to find any evidence of harm, so it's a bit conclusory. If someone wants to make an evidence-based argument that it's harmful and that almost nobody is using it (intentionally/correctly), the balance could swing the other way. That's for someone else to prove, though, since yes, at this point the bias has to be towards leaving things be.

John.

On Wed, Jan 25, 2017 at 12:45 John McCall via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jan 25, 2017, at 1:35 PM, Jacob Bandes-Storch <jtbandes@gmail.com <mailto:jtbandes@gmail.com>> wrote:

Agreed, IMO it would be quite dangerous for "a ??= b" to mean anything other than "a = a ?? b".

On another note, I don't see the value of "a? = b". I had never realized before that this works. Is this feature actually used in the wild? Should we consider removing it? (I could perhaps see some value if the assignment operator were overloadable, but it's not.)

The core semantics (that ? on an l-value still produces an l-value) fall out from the ability to call a mutating method with a?.foo(). Once you have that, you have to decide what it means to put such an l-value to the left of an assignment operator, and we decided to make it Just Work™. I agree that it is not a particularly useful operation in idiomatic Swift, especially with simple assignment (=), and we could consider just disallowing it.

It also comes up with optional properties, I think, which is something we weren't always certain we were going to ban in native Swift (as opposed to imported ObjC code, where they're a fact of life).

John.

Jacob

On Wed, Jan 25, 2017 at 10:28 AM, John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>> wrote:

On Jan 25, 2017, at 12:47 PM, Jacob Bandes-Storch via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Really? My observation from a quick test is that "a? = b" assigns b to a if a already has a value, or does nothing if it's nil. This is sort of the opposite of what's being proposed, which is that "a ?= b" should assign to a only if it does NOT have a value.

Right. On the other hand, this does seem like a poor spelling for the operator, given the ease of confusion.

Also, I'm finding it hard to imagine a use for this where the equivalent ?? invocation wouldn't be *much* clearer. It just feels like you must be doing something backwards — "I've filled in a default value for this variable, now overwrite it if this other value exists". Wouldn't the reverse generally be better?

John.

On Wed, Jan 25, 2017 at 9:33 AM Joe Groff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

> On Jan 25, 2017, at 8:40 AM, Nichi Shin via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
> I’d like to propose a new operator for optional assignment in Swift.
>
> The idea is that by using this operator (e.g. by doing a ?= b), the optional on the right would be assigned to the variable on the left only when it has something to assign (i.e. when it's not nil).

`a? = b` already does this. Maybe we need a fixit to make that more apparent, though.

-Joe

>
> The implementation could be something as follows:
>
> /// Optional Assignment Operator
> infix operator ?=: AssignmentPrecedence
>
> func ?=<T>(left: inout T, right: T?) {
> if right != nil {
> left = right!
> }
> }
>
> func ?=<T>(left: inout T?, right: T?) {
> if right != nil {
> left = right
> }
> }
>
> I hope you will consider adding this on a future release of this great programming language.
>
> Kind regards,
> N. S.
> _______________________________________________
> 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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

17

I'm just gonna weigh in with

1) I don't like optionals, I find them intrusive and prefer Objective C's message eating nil but whatever. I've shipped code in C, C++, and Java where dereferencing or messaging nil/null is "A Bad Thing (tm)" and its not really a driving issue in my coding or design.

2) I REALLY dislike operators. A lot. Like - they're punctuation, man. I can barely fathom the default set. They don't "say" anything to me as I read the code - they're syntactic noise.

I *much* prefer meaningful method names.

if let airportName = airports["DUB"] {
    print("The name of the airport is \(airportName).")
} else {
    print("That airport is not in the airports dictionary.")
}

vs (sorry, mixing languages)

airportName := airports at: #DUB ifAbsent: [ "unknown" ]
print("The name of the airport is \(airportName)")

One of these I can read, even as a lay person, and understand. The other is cartoon character cursing.

···

On Jan 25, 2017, at 11:39, John McCall via swift-evolution <swift-evolution@swift.org> wrote:

On Jan 25, 2017, at 2:37 PM, Jacob Bandes-Storch <jtbandes@gmail.com <mailto:jtbandes@gmail.com>> wrote:
If no uses are found (which I suspect will be the case), it becomes hard to also find evidence of harm other than in contrived scenarios. Perhaps contrived will be all we can find.

Well, if there's no harm, having a weird corner case that doesn't hurt anybody is fine. I certainly suspect that there are use cases for using a non-simple assignment operator there, so calling out = as a special case is a bit weird.

John.

Anyway, this is a bit off-topic for this thread...
On Wed, Jan 25, 2017 at 11:24 AM John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>> wrote:

On Jan 25, 2017, at 1:48 PM, Xiaodi Wu <xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com>> wrote:
Given lack of evidence of harm, is it really important to make such a source-breaking change?

My first instinct is that, no, it's not important. However, we haven't actually *tried* to find any evidence of harm, so it's a bit conclusory. If someone wants to make an evidence-based argument that it's harmful and that almost nobody is using it (intentionally/correctly), the balance could swing the other way. That's for someone else to prove, though, since yes, at this point the bias has to be towards leaving things be.

John.

On Wed, Jan 25, 2017 at 12:45 John McCall via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jan 25, 2017, at 1:35 PM, Jacob Bandes-Storch <jtbandes@gmail.com <mailto:jtbandes@gmail.com>> wrote:

Agreed, IMO it would be quite dangerous for "a ??= b" to mean anything other than "a = a ?? b".

On another note, I don't see the value of "a? = b". I had never realized before that this works. Is this feature actually used in the wild? Should we consider removing it? (I could perhaps see some value if the assignment operator were overloadable, but it's not.)

The core semantics (that ? on an l-value still produces an l-value) fall out from the ability to call a mutating method with a?.foo(). Once you have that, you have to decide what it means to put such an l-value to the left of an assignment operator, and we decided to make it Just Work™. I agree that it is not a particularly useful operation in idiomatic Swift, especially with simple assignment (=), and we could consider just disallowing it.

It also comes up with optional properties, I think, which is something we weren't always certain we were going to ban in native Swift (as opposed to imported ObjC code, where they're a fact of life).

John.

Jacob

On Wed, Jan 25, 2017 at 10:28 AM, John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>> wrote:

On Jan 25, 2017, at 12:47 PM, Jacob Bandes-Storch via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Really? My observation from a quick test is that "a? = b" assigns b to a if a already has a value, or does nothing if it's nil. This is sort of the opposite of what's being proposed, which is that "a ?= b" should assign to a only if it does NOT have a value.

Right. On the other hand, this does seem like a poor spelling for the operator, given the ease of confusion.

Also, I'm finding it hard to imagine a use for this where the equivalent ?? invocation wouldn't be *much* clearer. It just feels like you must be doing something backwards — "I've filled in a default value for this variable, now overwrite it if this other value exists". Wouldn't the reverse generally be better?

John.

On Wed, Jan 25, 2017 at 9:33 AM Joe Groff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

> On Jan 25, 2017, at 8:40 AM, Nichi Shin via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
> I’d like to propose a new operator for optional assignment in Swift.
>
> The idea is that by using this operator (e.g. by doing a ?= b), the optional on the right would be assigned to the variable on the left only when it has something to assign (i.e. when it's not nil).

`a? = b` already does this. Maybe we need a fixit to make that more apparent, though.

-Joe

>
> The implementation could be something as follows:
>
> /// Optional Assignment Operator
> infix operator ?=: AssignmentPrecedence
>
> func ?=<T>(left: inout T, right: T?) {
> if right != nil {
> left = right!
> }
> }
>
> func ?=<T>(left: inout T?, right: T?) {
> if right != nil {
> left = right
> }
> }
>
> I hope you will consider adding this on a future release of this great programming language.
>
> Kind regards,
> N. S.
> _______________________________________________
> 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 <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