[swift-evolution] [swift-evolution-announce] [Review] SE-0047 Defaulting non-Void functions so they warn on unused results

[Paul Ossenbruggen]

	• 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?
Yes

	• Does this proposal fit well with the feel and direction of Swift?
Yes

	• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
NA

	• 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
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160316/a25940a2/attachment.html>