<div dir="ltr"><div style="font-size:13px">> let _ = pop()</div><div style="font-size:13px">> However that's ugly just to remove the warning.<br></div><div style="font-size:13px"><br></div><div style="font-size:13px">As noted previously, the let is not necessary:</div><div style="font-size:13px">_ = pop()</div><div style="font-size:13px"><br></div><div style="font-size:13px"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 18, 2015 at 12:46 AM, Andrew Bennett via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I like this proposal, I'd also like it if using array.append warned you that you didn't actually call it (maybe it does in swift 2.2).<div><br></div><div>My only cornern is whether the following is ambiguous or not:</div><div> func pop() {}</div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> </span></font>func pop() -> Int { return 1 }<br><font size="2"><span style="background-color:rgba(255,255,255,0)"> </span></font>pop()<br><br>In my opinion that should call the first pop. Without the first pop that would probably have a warning, yet it is a common case to pop and ignore the value. I know I could do this:</div><div><br></div><div>let _ = pop()</div><div><br></div><div>However that's ugly just to remove the warning.</div><div><br></div><div>I agree with Tino,<span></span> returning Self should probably not have a warning.<div><div class="h5"><br><br>On Friday, 18 December 2015, Tino Heth via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> 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><br><blockquote type="cite"><div><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">It is a rare case for a result of a function to be unused – and most often it's caused by programmer having too little knowledge of the API.<span> </span></span></div></blockquote></div>I don't think this is a real life problem. When you have a class with something like "append" that doesn't change the receiver but returns a new object, it could be a valuable hint, but I don't like systems which assume that their users don't know what they are doing; and if this is actually the case, you are fighting a tough battle where a little warning wont help.<div><br></div><div>Please also note that ignoring a non-void return value can be absolutely ok in many situations: One example is returning self instead of useless void, which allows to build fluent interfaces - just because Cocoa didn't adopt the concept of method chaining from Smalltalk, it is still a interesting pattern which is used by other frameworks.</div><div><br></div><div>Imho warnings should be reserved for things that can be dangerous, and not to educate programmers...</div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=pQw7h83fWt3LLbgkfL4TSUL0weaZnVFZxDe5GShw4uTVG3N5D-2BRs1v60dlu-2FIl-2BcVrAKlupq9-2BYb0GXNj1hh1SMYAp6d2gpxdaBh06HR31R-2FQd1g5yEvG8RUqA0w9G5Ohc0eO4C3-2FHT6vekMUPSAFT0AA2rUmiN8IA1nuzYTkAq2R7-2FleQpc5Ebar8faeBaFGzsbXAnR9hcO4Se5lt3QnPAtbrZpjWtoDw96rDU0h-2BU-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>
</blockquote></div></div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=XvhdqKbdF5CD2eicBgtDxwV9X23JIVEhXYPY5ptMu9FHoRj91TSFpXLz7iH3AzgzUvA2N6-2BMpfsiPFOZJo39Ygm8pqFIwFoMcZ3qQ-2FC0x-2FAbiQirKhmL-2BzztK-2Ftq7kq8uPORBAFUCHz01iZUdR-2BOnfAsWYjw7creGk01o56tnuPSdodNaqZpWfEzrNtmXpcaGFseX1-2F7ER1dVGh4yhcfp5rccE-2BGCnBGMp1QWamRAak-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">
<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><br clear="all"><div><br></div>-- <br><div class="gmail_signature">bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden<br><a href="http://www.bitcycle.com/" target="_blank">http://www.bitcycle.com/</a><br>Phone: +46-73-753 24 62<br>E-mail: <a href="mailto:jens@bitcycle.com" target="_blank">jens@bitcycle.com</a><br><br></div>
</div>