[swift-evolution] Make non-void functions @warn_unused_result by default

Gwendal Roué gwendal.roue at gmail.com
Wed Mar 2 12:42:59 CST 2016

> Le 2 mars 2016 à 19:32, Stephen Celis <stephen.celis at gmail.com> a écrit :
>> Let’s imagine some code that is less implicit:
>> 	let _ = cart.remove(item)
>> What does it mean? Is it that the cart object was badly designed and that the result is an error that we ignore (bad)? Is it that the remove() method returns the removed object, as a confirmation of actual removal, that we ignore here (OK)? What is it? What is it?
> The fact that `_ =` prompts these questions is a good thing, in my opinion.

Yes, but it is not a good thing that it is impossible to lift the ambiguity in the current state of the proposal. But wait, you are starting to change my mind on the subject:

>> Some may import some foreign (yet valid) patterns like having the remove() function of a collection return the removed element (I didn’t have to look too far way: here is a lib with much hype theses days which does exactly that: https://github.com/lorentey/BTree/blob/master/Sources/BTree.swift#L507)
>> See?
>> With the new default, we have a real risk of indecipherable `let _ = …` surging here and there and everywhere. Just because developers will want to silence those unwanted warnings.
> Libraries with such behaviors would be free to design their API to suppress these warnings. The "risk" of `_ =` is reward: it's a loud signal that developers can't really ignore.

Pyry Jahkola has the same argument, and you are both right.

We can indeed hope that library writers will use their own code, and add the necessary @discardable modifier (assuming they test the naked form of their API). It’s an actual relief.

OK, I won’t be a vocal -1 any longer :-)

> (Also, a little reminder: you can write `_ =` and avoid the `let`.)

Thanks, I didn’t know!


More information about the swift-evolution mailing list