[swift-evolution] [Review] SE-0047 Defaulting non-Void functions so they warn on unused results

[Dave Abrahams]

on Wed Mar 23 2016, Andrey Tarantsov <swift-evolution at swift.org> wrote:

>> What is your evaluation of the proposal?
>
> -0.5 if the annotation is verbose (much longer than @discardable).
> +0.5 if the annotation is pleasant and concise, like @discardable
>
>> Is the problem being addressed significant enough to warrant a change to Swift?
>
> The warn-by-default behavior is mostly useless. The only reason to
> make the change is because “if we were designing Swift from scratch,
> this would probably be a slightly better default”.
>
> Most non-void functions are called for their result, and nobody ever
> forgets to use that result; if they do, it's like if they forgot to
> call the function altogether — trivial to find, not useful as a
> compiler diagnostic at all.
>
> The new default is better for:
>
> - (A) classes that provide both mutating and non-mutating methods;
> - (B) methods where forgetting to use the result produces a bug (a
> download task that needs to be resumed, an alert that needs to be
> displayed, a listener that needs to be stored somewhere, etc).

To be clear, the mistake this warning prevents is the unintentional call
to a non-mutating method when one thinks one is mutating the receiver.
This scenario can arise independently of A or B.

> The old default is better for:
>
> - (C) fluid APIs and other similar DSL scenarios;
> - (D) methods that are mainly invoked for their side effect and return a value “just in case”, like removing/adding elements, scheduling tasks, ...
>
> I've just scanned the entire Swift codebase I wrote since that fateful
> WWDC'14 (~20 kLOC excluding comments and blanks). I only have a
> handful of classes/methods in each category above, and annotating them
> one way or another is a trivial matter. Some of them *are not*
> currently annotated with @warn_unused_result, which is a point in
> favor of this proposal.
>
>> Does this proposal fit well with the feel and direction of Swift?
>
> I think the safe-by-default, explicit-opt-out behavior is a better default for Swift, although, like I've said, in practice it doesn't really matter much.
>
> Perhaps it's most useful for newcomers; you can easily skip over @warn_unused_result when learning Swift, but you won't be able ignore @discardable.
>
>> If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
>
> Haven't ever seen this in a language.
>
> Golang had a (not very informative) discussion on this topic at https://groups.google.com/forum/#!topic/golang-nuts/ksfgSWxJcCo
>
>> How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
>
> Closer to an in-depth study; looked at my Swift codebase, and read through all the discussions.
>
> On a side note, let me once again point to a dangerous trend in this
> mailing list: not looking at (or reporting on) how potential changes
> affect actual, specific, production code bases. We need a lot more of
> that in our reviews.
>
> Thanks,
>
> A.
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
Dave