Re: [swift-evolution] Optional Assignment Operator

[Freak Show via swift-evolution]

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 
>  wrote:
> 
>> On Jan 25, 2017, at 2:37 PM, Jacob Bandes-Storch > > 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 > > wrote:
>>> On Jan 25, 2017, at 1:48 PM, Xiaodi Wu >> > 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 
>>> > wrote:
 On Jan 25, 2017, at 1:35 PM, Jacob Bandes-Storch > 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 > wrote:
> On Jan 25, 2017, at 12:47 PM, Jacob Bandes-Storch via swift-evolution 
> > 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 

Re: [swift-evolution] Optional Assignment Operator

[Xiaodi Wu via swift-evolution]

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 
> 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  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 ?=(left: inout T, right: T?) {
> > if right != nil {
> > left = right!
> > }
> > }
> >
> > func ?=(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
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Optional Assignment Operator

[John McCall via swift-evolution]

> On Jan 25, 2017, at 2:37 PM, Jacob Bandes-Storch  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  > wrote:
>> On Jan 25, 2017, at 1:48 PM, Xiaodi Wu > > 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 
>> > wrote:
>>> On Jan 25, 2017, at 1:35 PM, Jacob Bandes-Storch >> > 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 >> > wrote:
 On Jan 25, 2017, at 12:47 PM, Jacob Bandes-Storch via swift-evolution 
 > 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 
 > wrote:
 
 > On Jan 25, 2017, at 8:40 AM, Nichi Shin via swift-evolution 
 > > 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 ?=(left: inout T, right: T?) {
 > if right != nil {
 > left = right!
 > }
 > }
 >
 > func ?=(left: inout T?, right: T?) {
 > if right != nil {
 > left = right
 > }
 > }
 >
 > I hope you will consider adding this on a future release of this great 
 > 

Re: [swift-evolution] Optional Assignment Operator

[Jacob Bandes-Storch via swift-evolution]

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  wrote:

> On Jan 25, 2017, at 1:48 PM, Xiaodi Wu  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 
> 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  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 ?=(left: inout T, right: T?) {
> > if right != nil {
> > left = right!
> > }
> > }
> >
> > func ?=(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
>
>
>
___
swift-evolution mailing list

Re: [swift-evolution] Optional Assignment Operator

[John McCall via swift-evolution]

> On Jan 25, 2017, at 1:48 PM, Xiaodi Wu  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 
> > wrote:
>> On Jan 25, 2017, at 1:35 PM, Jacob Bandes-Storch > > 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 > > wrote:
>>> On Jan 25, 2017, at 12:47 PM, Jacob Bandes-Storch via swift-evolution 
>>> > 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 
>>> > wrote:
>>> 
>>> > On Jan 25, 2017, at 8:40 AM, Nichi Shin via swift-evolution 
>>> > > 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 ?=(left: inout T, right: T?) {
>>> > if right != nil {
>>> > left = right!
>>> > }
>>> > }
>>> >
>>> > func ?=(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 
>>> 

Re: [swift-evolution] Optional Assignment Operator

[Daniel Duan via swift-evolution]

-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 
>  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  > wrote:
>> On Jan 25, 2017, at 12:47 PM, Jacob Bandes-Storch via swift-evolution 
>> > 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 
>> > wrote:
>> 
>> > On Jan 25, 2017, at 8:40 AM, Nichi Shin via swift-evolution 
>> > > 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 ?=(left: inout T, right: T?) {
>> > if right != nil {
>> > left = right!
>> > }
>> > }
>> >
>> > func ?=(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

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

Re: [swift-evolution] Optional Assignment Operator

[John McCall via swift-evolution]

> On Jan 25, 2017, at 1:35 PM, Jacob Bandes-Storch  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  > wrote:
>> On Jan 25, 2017, at 12:47 PM, Jacob Bandes-Storch via swift-evolution 
>> > 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 
>> > wrote:
>> 
>> > On Jan 25, 2017, at 8:40 AM, Nichi Shin via swift-evolution 
>> > > 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 ?=(left: inout T, right: T?) {
>> > if right != nil {
>> > left = right!
>> > }
>> > }
>> >
>> > func ?=(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

Re: [swift-evolution] Optional Assignment Operator

[Jacob Bandes-Storch via swift-evolution]

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  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 ?=(left: inout T, right: T?) {
>> > if right != nil {
>> > left = right!
>> > }
>> > }
>> >
>> > func ?=(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

Re: [swift-evolution] Optional Assignment Operator

[John McCall via swift-evolution]

> On Jan 25, 2017, at 12:47 PM, Jacob Bandes-Storch via swift-evolution 
>  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 
> > wrote:
> 
> > On Jan 25, 2017, at 8:40 AM, Nichi Shin via swift-evolution 
> > > 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 ?=(left: inout T, right: T?) {
> > if right != nil {
> > left = right!
> > }
> > }
> >
> > func ?=(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

Re: [swift-evolution] Optional Assignment Operator

[Jacob Bandes-Storch via swift-evolution]

Interesting, I think I misread it too. The one I was thinking of is the
same as the rejected proposal:
https://github.com/apple/swift-evolution/blob/master/proposals/0024-optional-value-setter.md

Jacob

On Wed, Jan 25, 2017 at 10:11 AM, Joe Groff  wrote:

>
> > On Jan 25, 2017, at 9:47 AM, Jacob Bandes-Storch 
> 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

Re: [swift-evolution] Optional Assignment Operator

[Derrick Ho via swift-evolution]

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

Re: [swift-evolution] Optional Assignment Operator

[Joe Groff via swift-evolution]

> On Jan 25, 2017, at 9:47 AM, Jacob Bandes-Storch  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

Re: [swift-evolution] Optional Assignment Operator

[Joe Groff via swift-evolution]

> On Jan 25, 2017, at 8:40 AM, Nichi Shin via swift-evolution 
>  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 ?=(left: inout T, right: T?) {
> if right != nil {
> left = right!
> }
> }
> 
> func ?=(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] Optional Assignment Operator

[Nichi Shin via swift-evolution]

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 ?=(left: inout T, right: T?) {
if right != nil {
left = right!
}
}

func ?=(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

Re: [swift-evolution] Optional Assignment Operator

[Psycho Hedgehog via swift-evolution]

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 
>  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 
>>  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 ?=(left: inout T, right: T?) {
>>if right != nil {
>>left = right!
>>}
>> }
>> 
>> func ?=(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

Re: [swift-evolution] Optional assignment operator

[Haravikk via swift-evolution]

Yeah, as previously discussed you’d usually be better doing something like:

struct Foo {
var value:Int?

func someMethod() {
let value = self.value ?? 0 // This is no longer 
optional
…
}
}

Since you end up with a non-optional version to work with, which this operator 
wouldn’t do (requiring you to unwrap it to use it anyway). To make the operator 
be as useful it would have to implicitly shadow the variable that it’s being 
assigned to, which would be strange and require some syntax of its own to be 
clear; in effect the ?? operator already has all the information you need as 
shown above, it’s a little longer but it’s more self-documenting so I think it 
covers the use-cases of an optional assignment pretty well.

> On 12 May 2016, at 23:12, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On May 12, 2016, at 2:38 PM, Tod Cunningham via swift-evolution 
>>  wrote:
>> 
>> I ended up creating a ??= operator about a month ago to do something very 
>> similar.  It’s a shame it won’t be made part of the official library.  
>> Although, it is very easy to add.
>> 
>> 
>> Just like the ?? operator the default value is only evaluated if the 
>> optional in nil.  However, unlike ?? it will
>> 
>> change the optional to be equal to the value on the right, iff the optional 
>> was nil.
> 
> We formally discussed & rejected this already:
> http://article.gmane.org/gmane.comp.lang.swift.evolution/7694
> 
> -Chris
> ___
> 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

Re: [swift-evolution] Optional assignment operator

[Chris Lattner via swift-evolution]

> On May 12, 2016, at 2:38 PM, Tod Cunningham via swift-evolution 
>  wrote:
> 
> I ended up creating a ??= operator about a month ago to do something very 
> similar.  It’s a shame it won’t be made part of the official library.  
> Although, it is very easy to add.
> 
> 
> Just like the ?? operator the default value is only evaluated if the optional 
> in nil.  However, unlike ?? it will
> 
> change the optional to be equal to the value on the right, iff the optional 
> was nil.

We formally discussed & rejected this already:
http://article.gmane.org/gmane.comp.lang.swift.evolution/7694

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

Re: [swift-evolution] Optional assignment operator

[Tod Cunningham via swift-evolution]

I ended up creating a ??= operator about a month ago to do something very 
similar.  It’s a shame it won’t be made part of the official library.  
Although, it is very easy to add.


Just like the ?? operator the default value is only evaluated if the optional 
in nil.  However, unlike ?? it will

change the optional to be equal to the value on the right, iff the optional was 
nil.


infix operator ??= {

associativity right

precedence 90

assignment

}


public func ??=(inout optional: VALUE?, @autoclosure defaultValue: () 
throws -> VALUE) rethrows -> VALUE {

if let value = optional {

return value

} else {

let value = try defaultValue()

optional = value

return value

}

}


- Tod

From: 
<swift-evolution-boun...@swift.org<mailto:swift-evolution-boun...@swift.org>> 
on behalf of Trent Nadeau via swift-evolution 
<swift-evolution@swift.org<mailto:swift-evolution@swift.org>>
Reply-To: Trent Nadeau <tanad...@gmail.com<mailto:tanad...@gmail.com>>
Date: Thursday, May 12, 2016 at 10:52 AM
To: Rod Brown <rodney.bro...@icloud.com<mailto:rodney.bro...@icloud.com>>
Cc: Douglas Gregor via swift-evolution 
<swift-evolution@swift.org<mailto:swift-evolution@swift.org>>
Subject: Re: [swift-evolution] Optional assignment operator

This same operator (except spelled as ??=) was up as a proposal and rejected in 
February. See http://thread.gmane.org/gmane.comp.lang.swift.evolution/7694.

On Thu, May 12, 2016 at 10:41 AM, Rod Brown via swift-evolution 
<swift-evolution@swift.org<mailto:swift-evolution@swift.org>> wrote:
I’m tentatively supportive of this proposal. I definitely see the use case 
(assign only if not not nil).  Interested to hear the opinions of others here :)

-Rod


> On 12 May 2016, at 11:59 PM, Jose Manuel Sánchez Peñarroja via 
> swift-evolution <swift-evolution@swift.org<mailto:swift-evolution@swift.org>> 
> wrote:
>
> Sorry if this has already been discussed, if so I couldn’t find it.
>
> I would like to propose to add to Swift an optional assignment operator ?=
> I think this would nicely align with the other uses of ?, and avoid 
> repetition in this case:
>
>   var value = 5
>
>   var possibleNewValue: Int? = nil
>
>   value = possibleNewValue ?? value
>
> It would be used like this:
>
>   value ?= possibleNewValue
>
> I’ve found quite a few cases in which this would be very useful to me. It is 
> already possible to implement it, but having it defined in the standard 
> library would define an standard, and prevent different semantics depending 
> on who implements it.
>
>
>   infix operator ?= {
> associativity right
>  precedence 90
>  assignment
>   }
>
>   func ?= (inout lhs: T, rhs: T?) {
>   lhs = rhs ?? lhs
>   }
>
>
> Regards,
> José Manuel Sanchez
> ___
> 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



--
Trent Nadeau
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Optional assignment operator

[Trent Nadeau via swift-evolution]

This same operator (except spelled as ??=) was up as a proposal and
rejected in February. See
http://thread.gmane.org/gmane.comp.lang.swift.evolution/7694.

On Thu, May 12, 2016 at 10:41 AM, Rod Brown via swift-evolution <
swift-evolution@swift.org> wrote:

> I’m tentatively supportive of this proposal. I definitely see the use case
> (assign only if not not nil).  Interested to hear the opinions of others
> here :)
>
> -Rod
>
>
> > On 12 May 2016, at 11:59 PM, Jose Manuel Sánchez Peñarroja via
> swift-evolution  wrote:
> >
> > Sorry if this has already been discussed, if so I couldn’t find it.
> >
> > I would like to propose to add to Swift an optional assignment operator
> ?=
> > I think this would nicely align with the other uses of ?, and avoid
> repetition in this case:
> >
> >   var value = 5
> >
> >   var possibleNewValue: Int? = nil
> >
> >   value = possibleNewValue ?? value
> >
> > It would be used like this:
> >
> >   value ?= possibleNewValue
> >
> > I’ve found quite a few cases in which this would be very useful to me.
> It is already possible to implement it, but having it defined in the
> standard library would define an standard, and prevent different semantics
> depending on who implements it.
> >
> >
> >   infix operator ?= {
> > associativity right
> >  precedence 90
> >  assignment
> >   }
> >
> >   func ?= (inout lhs: T, rhs: T?) {
> >   lhs = rhs ?? lhs
> >   }
> >
> >
> > Regards,
> > José Manuel Sanchez
> > ___
> > 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
>



-- 
Trent Nadeau
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Optional assignment operator

[Rod Brown via swift-evolution]

I’m tentatively supportive of this proposal. I definitely see the use case 
(assign only if not not nil).  Interested to hear the opinions of others here :)

-Rod


> On 12 May 2016, at 11:59 PM, Jose Manuel Sánchez Peñarroja via 
> swift-evolution  wrote:
> 
> Sorry if this has already been discussed, if so I couldn’t find it.
> 
> I would like to propose to add to Swift an optional assignment operator ?=
> I think this would nicely align with the other uses of ?, and avoid 
> repetition in this case:
> 
>   var value = 5
> 
>   var possibleNewValue: Int? = nil
> 
>   value = possibleNewValue ?? value
> 
> It would be used like this:
> 
>   value ?= possibleNewValue
> 
> I’ve found quite a few cases in which this would be very useful to me. It is 
> already possible to implement it, but having it defined in the standard 
> library would define an standard, and prevent different semantics depending 
> on who implements it.
> 
> 
>   infix operator ?= {
> associativity right
>  precedence 90
>  assignment
>   }
> 
>   func ?= (inout lhs: T, rhs: T?) {
>   lhs = rhs ?? lhs
>   }
> 
> 
> Regards,
> José Manuel Sanchez
> ___
> 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] Optional assignment operator

[Jose Manuel Sánchez Peñarroja via swift-evolution]

Sorry if this has already been discussed, if so I couldn’t find it.

I would like to propose to add to Swift an optional assignment operator ?=
I think this would nicely align with the other uses of ?, and avoid repetition 
in this case:

var value = 5

var possibleNewValue: Int? = nil

value = possibleNewValue ?? value

It would be used like this:

value ?= possibleNewValue

I’ve found quite a few cases in which this would be very useful to me. It is 
already possible to implement it, but having it defined in the standard library 
would define an standard, and prevent different semantics depending on who 
implements it.


infix operator ?= {
  associativity right
   precedence 90
   assignment
}

func ?= (inout lhs: T, rhs: T?) {
lhs = rhs ?? lhs
}


Regards,
José Manuel Sanchez
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution