> On Jan 25, 2017, at 1:35 PM, Jacob Bandes-Storch <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 https://lists.swift.org/mailman/listinfo/swift-evolution
