[swift-evolution] [swift-evolution-announce] [Review] SE-0047 Defaulting non-Void functions so they warn on unused results
possen at gmail.com
Wed Mar 16 23:09:50 CDT 2016
• What is your evaluation of the proposal?
+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.
• Is the problem being addressed significant enough to warrant a change to Swift?
• Does this proposal fit well with the feel and direction of Swift?
• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Been following and contributing to discussion and read the proposal.
> On Mar 16, 2016, at 5:57 PM, Erica Sadun via swift-evolution <swift-evolution at swift.org> wrote:
>> On Mar 16, 2016, at 5:27 PM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
>>> • What is your evaluation of the proposal?
>> 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.
> 1. The keyword will be used rarely. I don't mind if it's slightly hard to type.
> 2. When used, it should be as clear as possible, both in understanding what it does and visually standing out.
> 3. The most popular keyword requested was actually @allowUnusedResult followed by @suppressUnusedResultWarning.
> Both of these are longer. I felt @discardableResult was more descriptive than @allowUnusedResult. I wanted to avoid
> the word "suppress" as it is appears on many frequently misspelled words lists.
> I believe discardable (the number one choice by *far* for a type annotation, with ignorable as its second) perfectly describes
> how the return value/result should be treated. When included, the behavior mimics:
> let _ = resultReturningFunctionOfSomeType()
> which basically discards the result (an active decision) rather than ignores it (a passive one).
>> 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.
> 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
> on his own. The entire point of this exercise is to reduce likely error points. Simply changing the behavior without fixits
> should help accomplish that in existing code. If you add @discardableResult, we mask the advantage this behavior
> should address.
>>> • Is the problem being addressed significant enough to warrant a change to Swift?
>> 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.
> And that's why I don't think the migrator should make any code changes.
> -- E
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution