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