<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div>I am also strongly in favor of this proposal.</div><div><div class=""><br class=""></div><div class="">There are probably enough valid use cases for a <font face="Menlo" class="">@suppress_unused_warning</font> but personally I don't think <font face="Menlo" class="">pop()</font> is a great example.</div><div class=""><br class=""></div><div class="">I think a second method à la <font face="Menlo" class="">dropFirst/Last/...</font> that returns <font face="Menlo" class="">Void</font> would be better at communicating intent and allows <font face="Menlo" class="">pop()</font> to retain the warning.</div><div class=""><br class=""></div><div class="">- Janosch</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class="">On 18 Dec 2015, at 21:48, Erica Sadun 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=""><div class="">I vote +1 in favor of making warn_unused_result the default. It's simple, elegant, logical, functional, and will reduce stdlib clutter.</div><div class=""><br class=""></div><div class="">As for replacing it? Although I'd probably be okay with <font face="Courier" class="">suppress_unused_warning</font>, please consider <font face="Courier" class="">optional hey_no_worries_mate_on_unused</font>, <font face="Courier" class="">unused_is_mellow</font>, or <font face="Courier" class="">dont_harsh_my_unused</font>. Supporting <font face="Courier" class="">_ = pop()</font> without further warning is icing on the cake, as it enables the behavior to be established at either the API or consuming end.</div><div class=""><br class=""></div><div class="">-- E</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="">On Dec 18, 2015, at 1:25 PM, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><blockquote type="cite" class="">On Dec 18, 2015, at 3:47 AM, Tino Heth via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">_ = pop()<br class=""></blockquote><br class="">Now that's what I'd call ugly - I vote against everything that forces me to use more underscores ;-)<br class=""></blockquote><div class=""><br class=""></div>“pop()” is an example of the comparatively-rare method that one might want to annotate to avoid the warning: the side-effect is useful even if you’re dropping the result. We’re only talking about making warn_unused_result the <i class="">default</i>, not making it the only option.<div class=""><br class=""><div class="">-Dave<br class=""></div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=r5jpKsi6nat7oa43lpCLi5GRGm2utDkbDscuFklXZ2eMg6tyNY5ilFesYh1pku0Ezh6w-2BOW6oXfnb0Su5NH8kp6fWchT2zJyY38fDCAY2HFQOhX5UCFe-2By6e-2BIyCJqeI4MJAHUab74SGgKEwxdDjaPoC-2BW8yfT-2BRSsBGebwa2QybdqoyjP1VpBHCF5gVCEVyaOOJcb3XrLSQm5o-2B64bj10KjLYyf7S9TDzZ2IXzqW8Q-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
</div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class="">
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=TgVqANlJg1jmZHvvWyiennS7-2BVfVoMMKBBaiUKdUvoaaRcSIkne-2FpwH6O3oPJWJLIOrIg8IHXcHALk2uCruYZ5eqAt0xNJnzMJGQ5juL-2FiGS-2FQFd-2Fh3hU-2BPJ3EcINuP9Y-2FXVFrgb5y4up4i3sZl8C8xaLL1Fp3RHzFtjitAEAeYnmLRgWTQ0xaZLE4AGW7aYS2FYMwcZ3RjtFAEyE2Aepz-2FfMbNW68ENbTxo9deDip4-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
</div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>