> On Mar 16, 2016, at 5:27 PM, Brent Royal-Gordon via swift-evolution
> <swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
