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

[Step C]

> On Mar 2, 2016, at 7:20 AM, Tino Heth via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> Macho posturing about how only bad programmers need safety is not helpful
> I'm not arguing against safety at all — but safeguards sacrificing ease of use often open a new can of worms.
> Swift is already quite "mothering" with its warnings, and I'd rather move some checks to a separate analyze-step than adding new ones (one example are the hints to replace "var" with "let", which are a constant distraction until I finally write the line with the change…)

This is a good point. I love the warning about var and let usage, but it is very annoying while I am writing. It is much more useful when I have finished a section and want to build.

This might be worth a separate thread, and might be more about Xcode's choices of what static analysis checks to run and when, or for haps a discussion about when morning should be shown or suppressed during code writing.

> It is fine to throw a warning for pure functions, and it is good practice to annotate methods that can be misinterpreted easily, but I'd rather trust in the developer discarding a result in most other situations.
It is not just about trusting the developer, but when someone later goes to edit the code will they know whether the ignored result was intentional or not? 

> The compiler can't know wether a method was called for its side effects, so I prefer to leave this decision to the human using it — he should know.
> 
> You may code in a different style as Andrey and I, but discardable return values are no anti-pattern, so I don't think they should be punished with a monstrosity like "@dont_warn_unused_result" (shiver).
> 
> - Tino
> 
> I myself break the most prominent programmer cliches easily (including the ability to cook quiche that has never seen a freezer ;-), but apparently, I should strive for more bluntness, as it greatly increases the chances for reactions...
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution