<div dir="ltr">Not that it seems highly contested, but +1 from me as well.<div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div>Jacob<br></div></div></div></div>
<br><div class="gmail_quote">On Fri, Dec 18, 2015 at 2:01 PM, Janosch Hildebrand via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>I am also strongly in favor of this proposal.</div><div><div><br></div><div>There are probably enough valid use cases for a <font face="Menlo">@suppress_unused_warning</font> but personally I don&#39;t think <font face="Menlo">pop()</font> is a great example.</div><div><br></div><div>I think a second method à la <font face="Menlo">dropFirst/Last/...</font> that returns <font face="Menlo">Void</font> would be better at communicating intent and allows <font face="Menlo">pop()</font> to retain the warning.</div><div><br></div><div>- Janosch</div><div><div class="h5"><div><br></div><blockquote type="cite"><div>On 18 Dec 2015, at 21:48, Erica Sadun via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br><div><div style="word-wrap:break-word"><div>I vote +1 in favor of making warn_unused_result the default. It&#39;s simple, elegant, logical, functional, and will reduce stdlib clutter.</div><div><br></div><div>As for replacing it? Although I&#39;d probably be okay with <font face="Courier">suppress_unused_warning</font>, please consider <font face="Courier">optional hey_no_worries_mate_on_unused</font>, <font face="Courier">unused_is_mellow</font>, or <font face="Courier">dont_harsh_my_unused</font>. Supporting <font face="Courier">_ = 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><br></div><div>-- E</div><div><br></div><div><blockquote type="cite"><div>On Dec 18, 2015, at 1:25 PM, Dave Abrahams via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><div><div style="word-wrap:break-word"><br><blockquote type="cite">On Dec 18, 2015, at 3:47 AM, Tino Heth via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br><br><blockquote type="cite">_ = pop()<br></blockquote><br>Now that&#39;s what I&#39;d call ugly - I vote against everything that forces me to use more underscores ;-)<br></blockquote><div><br></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>default</i>, not making it the only option.<div><br><div>-Dave<br></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="min-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">
</div>
_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br>
<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="min-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">
</div>
_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div></div></div><br>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=P-2BsYbBZHRBuLDBJaL4DIKDNfkkjpROowTyRAObV11qzj-2BhvPQPAmQab-2Bl3I1hRK-2BtJq3wjHsLPXHjdtO7plTZ2nZTtaQwGX9pNSnMH2tr26nmNoJcX8eca6uCdVHHpscpFo5G5q12AXVnsXdoYwyRbKOUCrdEsK3FqgbJPAdcJTH0a3cFqVTZzqccfpIYexWXAXi11QLowoGBEfFBAoF2iM13ArHQOEpxsKrGwENWhQ-3D" alt="" width="1" height="1" border="0" style="min-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">
</div>
<br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div></div>