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 < [email protected]> wrote: > On Jan 25, 2017, at 1:35 PM, Jacob Bandes-Storch <[email protected]> > 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 <[email protected]> wrote: > > On Jan 25, 2017, at 12:47 PM, Jacob Bandes-Storch via swift-evolution < > [email protected]> 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 < > [email protected]> wrote: > > > > On Jan 25, 2017, at 8:40 AM, Nichi Shin via swift-evolution < > [email protected]> 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 > > [email protected] > > https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
