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

Tino Heth 2th at gmx.de
Thu Feb 25 05:07:21 CST 2016

> What about @warnUnusedResult being implied for @pure functions, and leaving it off by default for everything else? 
I think this is the right way.
Ignoring the result of a call to a pure function is suspicious and most likely an error — but anything else is imho just dry-nursing developers:
As library author, I have to assume that clients have an idea of what they are doing; when someone uses my methods without knowing basic stuff like relevance of the return value, I can't enlighten him with with a warning that is nothing but annoyance for those who know what they are doing.

A monstrosity like "dont_warn_unused_result" would more or less discourage things like chaining, and the language imho shouldn't push you into that direction.
Of course, the status quo isn't good either, as @warn_unused_result is a ugly burden for those who want to give hints in their libraries…

I like Brents idea of putting the annotation next to the return type to indicate its effect, but prefer a variant:
mutating func nearlyPureMethod() @vital -> Type
(although I see dangers with this approach: "const" in C++ for example is imho quite confusing because its meaning depends on its position)

Something like
@void func canIgnoreResult(input: String) -> String
would be concise, but just because it looks familiar to many developes, it could be confusing as well.

A first thought was
func canIgnoreResult(input: String) -> Void|String
but on a second glance, I would rather expect such a return type to behave like String?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2448 bytes
Desc: not available
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160225/06be5b28/attachment.p7s>

More information about the swift-evolution mailing list