<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div><br></div><div><br>Le 25 févr. 2016 à 08:50, Haravikk via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> a écrit :<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><br class=""><div><blockquote type="cite" class=""><div class="">On 25 Feb 2016, at 05:19, Paul Ossenbruggen via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">These lack conciseness. What about the already supported: <div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div style="font-size: 13px;" class=""><b class="">let _ = </b>ingoreResult()</div></blockquote></div></div></blockquote><br class=""></div><div>This could work until we gain some other, general purpose, method to suppress warnings, though it isn’t pretty IMO. For example, if a class’ methods are designed to be chain able then the result isn’t necessary (it’s just self), so in things like loops you could end up having to use let _ an awful lot, like so:</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>class Chainable {</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>var value = 0</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>func add(add:Int) {</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>value += add</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>return self</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>let chainable = Chainable()</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>for _ in 0 ..< 10 {</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>if getSomeCondition() {</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>let _ = chainable.add(5)</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>} else {</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>let _ = chainable.add(2)</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div><br class=""></div><div>Stupid example, but imagine if there were a few other operations, perhaps handled by other conditionals, then suddenly you end up with a lot of these let _ statements, which is why being able to suppress the warnings in all cases is still desirable.</div></div></blockquote><div><br></div><div>You convince me here. The two ways to ensure we do this deliberately seem useful and not conflicting. </div><br><blockquote type="cite"><div><div>On the topic of verbosity in the attribute, I don’t think there’s any need to go to four words; the current attribute is @warn_unused_result, and I think that @ignore_unused_result works a direct opposite (i.e- the result being unused is still strange to the compiler, but it chooses not to issue a warning about it). I’m only using snake case because that’s what the current value has, obviously we’ll adjust for whatever the final attribute naming convention turns out to be.</div></div></blockquote><div><br></div>+1 Coherent, expressive and short!<div><br></div><div>Mathieu</div><div><br></div><div><br><div><br><div><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></div></div></body></html>