I think I see Alex's point here. Optional chaining is still intended to be a
substitute for Objective-C's nil-swallowing, and therefore foo?.bar() should
not warn if 'bar' has a discardable result, even though there is semantic
information about whether the method was actually called. I think that of the
three things under consideration here:
1. foo?.bar() should not warn
2. foo.map(baz) should warn
3. Ternaries should be consistent with non-ternaries
#1 is the most important, at least to me. The Swift 3 change was to sacrifice
#2 in favor of #3, which I'm not sure I would have done, but I wouldn't want to
sacrifice #1 in favor of #2.
I wouldn't mind the model of the type being '@discardableResult Optional<Void>'
or whatever, but I think that's probably more work than anyone wants to sign up
for.
Jordan
> On Jan 31, 2017, at 08:16, Daniel Duan via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> Good to know the history. If I were to fix the inconsistency, I'd add the
> warning to optional chaining instead.
>
> Deliberately make the compiler give us *less* information for esthetic
> reasons feels wrong to me. As I mentioned in the original email, this has
> cost us a few unnoticed bad patterns slipping into our production. That's the
> opposite of what this type of warning is supposed to achieve.
>
>> On Jan 31, 2017, at 1:07 AM, Alex Hoppen <a...@ateamer.de> wrote:
>>
>> This was a deliberate change between Swift 3 beta 1 and beta 2 after a
>> friend of mine pointed the following inconsistency out to me:
>>
>> struct Foo {
>> func bar() {}
>> }
>> let foo: Foo? = Foo()
>> foo?.bar() // Does not create a warning
>> true ? foo?.bar() : foo?.bar() // expression of type '()?' is unused
>>
>> After some offline discussion at WWDC with the Swift team we decided to move
>> to a consistent model where ()?, ()??, … is always discardable since we
>> didn't want to take the convenience of foo?.bar() away (something that
>> regularly occurs with weak variables, e.g. captures in closures).
>>
>> So much for the history of this feature.
>>
>> – Alex
>>
>>
>>> On 30 Jan 2017, at 22:58, Daniel Duan via swift-evolution
>>> <swift-evolution@swift.org> wrote:
>>>
>>> Hi all,
>>>
>>> Right now, expressions that evaluates to Optional<()>,
>>> Optional<Optional<()>>… gets special treatment when it’s unused. For
>>> example:
>>>
>>> func f(s: String) {}
>>> let s: String = “”
>>> s.map(f) // no warning here, even tho the resulting type is `Optional<()>`
>>> and unused.
>>>
>>> func g() throws {}
>>> try? g() // no warnings here neither.
>>>
>>> This is convenient, but encourages composing map/filter/reduce, etc with
>>> side-effect-ful functions, which we have found a few cases of in our
>>> production code recently. Granted, these cases could’ve been caught with
>>> more careful code reviews. But we wouldn’t have missed them if this
>>> “feature” didn’t exist.
>>>
>>> I think we should remove the special treatment so that code in the example
>>> above would generate a warning about `()?` being unused. Users can silence
>>> it manually by assigning the result to `_`.
>>>
>>> OTOH, this would undermine the convenience of `try?` when the throwing
>>> function don’t return anything.
>>>
>>> What do y’all think?
>>>
>>> Daniel Duan
>>> _______________________________________________
>>> 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
