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@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@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@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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
