[swift-evolution] [Review] SE-0047 Defaulting non-Void functions so they warn on unused results
Tino Heth
2th at gmx.de
Fri Mar 18 07:51:58 CDT 2016
> • What is your evaluation of the proposal?
-1
This clearly makes me part of a small minority, but I doubt that the participants of this discussion are representative for all current and future users of Swift:
Those who enjoy tinkering with the design of languages naturally strive for a tool that can't be used in wrong ways — but that goal is just impossible, and we shouldn't sacrifice ease of use for a safety measure that as little value in reality.
Swift is rather young, so I don't think that analyzing existing code bases is a valid way to prove that superfluous "unused-result" warnings won't become an annoyance later.
There are situations where warn_unused_result is really useful, but the examples presented in this thread fail to illustrate why the behavior should be made default:
Sure, it is obviously strange when someone creates an object and doesn't do anything with it — so this should be a warning (or even an error), right?
I say no, because obvious errors are easy to find, and a compiler should focus on subtle ones.
Swift isn't a pure functional language, and despite their bad reputation here, the side effects might have been the motivation for a call — and its illusive that anyone knows in advance why a non-pure method is called.
> • Is the problem being addressed significant enough to warrant a change to Swift?
Yes, but I disagree with the proposed change.
The default should be kept, but it should be more comfortable to activate the warning — or to deactivate it, if the default is changed:
This is all personal preference, so it should be up to the author of a method to decide how important its result is, and there shouldn't be strong pressure to either direction.
> • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Took part in the discussion in an early stage, read most posts
Tino
More information about the swift-evolution
mailing list