<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div>On Thu, Dec 10, 2015, at 04:41 PM, Dmitri Gribenko via swift-evolution wrote:<br></div>
<blockquote type="cite"><div dir="ltr"><div><div>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.&nbsp; With classes, especially Cocoa ones, it might not be the case.&nbsp; It would be good if someone investigated how this change would affect a class-heavy library, e.g., Foundation.<br></div>
</div>
</div>
</blockquote><div>&nbsp;</div>
<div>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.<br></div>
<div>&nbsp;</div>
<div>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. Where it would primarily be expected is on functions that look like they might be mutating but aren't (think `sort()` vs `sortInPlace()`), or on functions that return an object whose deinit triggers behavior that negates the function call (e.g. some sort of `open()` that returns a File object). I think the stdlib uses it a disproportionate amount because the stdlib is used by everybody, and adding the attribute to stdlib declarations therefore has a huge reach for little effort and in particular it may help neophyte programmers.<br></div>
<div>&nbsp;</div>
<div>I will accept that most calls to nonmutating methods on structs and enums are probably good candidates for @warn_unused_result, I'm just arguing that in most cases outside of the stdlib there's low reward for adding it, and I worry that if we make it the default then we run the risk of punishing users of side-effectful APIs where the API designer never actually tried ignoring the results.<br></div>
<div>&nbsp;</div>
<div>I do support&nbsp;Kametrixom's idea of a @pure attribute that implies both @effects(readnone) and @warn_unused_result.<br></div>
<div>&nbsp;</div>
<div>-Kevin Ballard</div>
</body>
</html>