• 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
> <[email protected]> wrote:
>
>
>> On Mar 16, 2016, at 5:27 PM, Brent Royal-Gordon via swift-evolution
>> <[email protected]> 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
