> • 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
