This inconsistency could be solved by giving optionals a method to specifically perform side effects.
In the same way that arrays have a 'map' function for retuning new arrays and a 'forEach' to return '()' and perform a side effects. Option could have a 'forEach' method that returns '()'.
s.map(print) // would trigger a "unused result warning"
s.forEach(print) // would not trigger any warning
The naming is definitely debatable, but I think the idea is worth considering.
Andre Videla
> On 31 Jan 2017, at 17:47, Alex Hoppen via swift-evolution <swift-evolution at swift.org> wrote:
>> Amendment to the history of the bug after I had a look at the bug reports again: SR-1895 explicitly asked that
>> let s: String? = "hi"
> s.map {print($0)}
>> should not produce any warnings while it did so during beta 1.
>> – Alex
>>> On 31 Jan 2017, at 09:07, Alex Hoppen via swift-evolution <swift-evolution at swift.org> 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 at 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 at swift.org>>>https://lists.swift.org/mailman/listinfo/swift-evolution>>>> _______________________________________________
>> swift-evolution mailing list
>>swift-evolution at swift.org>>https://lists.swift.org/mailman/listinfo/swift-evolution>> _______________________________________________
> swift-evolution mailing list
>swift-evolution at swift.org>https://lists.swift.org/mailman/listinfo/swift-evolution-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170204/b37478e0/attachment.html>