> On Jan 25, 2017, at 1:48 PM, Xiaodi Wu <xiaodi...@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 <jtban...@gmail.com >> <mailto:jtban...@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 <rjmcc...@apple.com >> <mailto:rjmcc...@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 >>> > <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 >>> <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 >>> <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 > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
