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

[Dmitri Gribenko]

On Fri, Dec 11, 2015 at 11:11 PM, Kevin Ballard via swift-evolution <
swift-evolution at swift.org> wrote:

> On Thu, Dec 10, 2015, at 04:41 PM, Dmitri Gribenko via swift-evolution
> wrote:
>
> We have discussed this internally in the past, and we found that
> non-mutating methods on structs and enums are usually @warn_unused_result,
> it is a quite strong heuristic.  With classes, especially Cocoa ones, it
> might not be the case.  It would be good if someone investigated how this
> change would affect a class-heavy library, e.g., Foundation.
>
>
> I'm curious, what code did you look at to develop this heuristic? I've
> noticed that the stdlib uses a lot of @warn_unused_result, but I don't
> think I've ever actually seen anyone bother to use it in any of the
> third-party Swift code that I've inspected.
>

Primarily standard library code, yes, and we took a quick look at a few
third-party projects from github.


> My general feeling here is that, while most non-mutating functions that
> return results probably aren't worth calling if you ignore the results,
> that doesn't mean that @warn_unused_result is actually something that
> should necessarily be expected to put on the declaration.
>

Exactly -- so if the compiler just inferred the attribute in those cases
where we have a strong heuristic, it would be a win-win situation.


> I do support Kametrixom's idea of a @pure attribute that implies both
> @effects(readnone) and @warn_unused_result.
>

@pure and @effects are both attributes with ABI implications.  The compiler
can't infer them without constraining future library evolution.  So while I
agree in general that something like @pure is a good direction to explore,
it won't necessarily cover all usecases of @warn_unused_result (of course,
depending on the semantics of @pure, which we have yet to define).

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151212/16e6bf01/attachment.html>