<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=""><b class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>• What is your evaluation of the proposal?</b><div class="">+1 on proposal overall. I agree that @discardable is sufficient to describe what it does. If there is questions it is easy to search it on the web. Also the context of where the @discardable modifier is on the line will reduce ambiguity. Conciseness is important and I don’t think it significantly detracts from the clarity to leave off the “Return” part. </div><div class=""><br class=""><b class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>• Is the problem being addressed significant enough to warrant a change to Swift?</b></div><div class="">Yes</div><div class=""><br class=""><b class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>• Does this proposal fit well with the feel and direction of Swift?<br class=""></b></div><div class=""><span class="Apple-tab-span" style="white-space: pre;"><span style="white-space: normal;" class="">Yes</span></span></div><div class=""><span class="Apple-tab-span" style="white-space: pre;"><span style="white-space: normal;" class=""><br class=""></span><b class=""> </b></span><b class="">• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br class=""></b></div><div class=""><span class="Apple-tab-span" style="white-space: pre;"><span style="white-space: normal;" class="">NA</span></span></div><div class=""><span class="Apple-tab-span" style="white-space: pre;"><span style="white-space: normal;" class=""><br class=""></span><b class=""> </b></span><b class="">• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br class=""></b><div><br class=""></div><div>Been following and contributing to discussion and read the proposal. </div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class="">On Mar 16, 2016, at 5:57 PM, 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=""><div class=""><br class=""><blockquote type="cite" class="">On Mar 16, 2016, at 5:27 PM, Brent Royal-Gordon 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=""><span class="Apple-tab-span" style="white-space:pre"> </span>• What is your evaluation of the proposal?<br class=""></blockquote><br class="">I am in favor of the semantic, but I don't like `@discardableResult`; it's long and unwieldy. I would prefer that we either use a shorter word than "discardable", attach the keyword to the return type as discussed in "Future Directions", or both.<br class=""><br class=""></blockquote><br class="">1. The keyword will be used rarely. I don't mind if it's slightly hard to type.<br class="">2. When used, it should be as clear as possible, both in understanding what it does and visually standing out.<br class="">3. The most popular keyword requested was actually @allowUnusedResult followed by @suppressUnusedResultWarning. <br class=""> Both of these are longer. I felt @discardableResult was more descriptive than @allowUnusedResult. I wanted to avoid<br class=""> the word "suppress" as it is appears on many frequently misspelled words lists. <br class=""><br class=""> I believe discardable (the number one choice by *far* for a type annotation, with ignorable as its second) perfectly describes<br class=""> how the return value/result should be treated. When included, the behavior mimics:<br class=""><br class=""> let _ = resultReturningFunctionOfSomeType()<br class=""><br class=""> which basically discards the result (an active decision) rather than ignores it (a passive one).<br class=""><br class=""><blockquote type="cite" class="">I also don't like that this proposal doesn't include an "Impact on existing code" section. We ought to decide whether the migrator will add `@discardableResult` to existing symbols or not.<br class=""></blockquote><br class="">This is a good point and Adrian and I will be happy to add this in. I do not believe it should, although I'll let Adrian answer<br class="">on his own. The entire point of this exercise is to reduce likely error points. Simply changing the behavior without fixits<br class="">should help accomplish that in existing code. If you add @discardableResult, we mask the advantage this behavior<br class="">should address.<br class=""><br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• Is the problem being addressed significant enough to warrant a change to Swift?<br class=""></blockquote><br class="">Yes. I should use `@warn_unused_result`, but never bother because it's just too much of a hassle. My code will be safer with this change.<br class=""></blockquote><br class="">And that's why I don't think the migrator should make any code changes.<br class=""><br class="">-- E<br class=""><br class="">_______________________________________________<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></div></blockquote></div><br class=""></div></body></html>