[swift-evolution] [Review] SE-0047 Defaulting non-Void functions so they warn on unused results
Adrian Kashivskyy
adrian.kashivskyy at me.com
Thu Mar 17 01:46:26 CDT 2016
@Patrick,
> I rarely use the result value of removeLast() and I don't see how requiring it here adds any safety. It is obvious this call has side-effects and doesn't just return the last element.
Actually, removeLast() and other pop()-like functions are examples of functions that will most probably be marked with @discartableResult attribute.
————————————————————
@Brent,
> 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.
That was the first idea, but it has been changed to function declaration attribute, per core team design discussion <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160314/012823.html>.
> 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.
I totally agree with Erica – the migrator should only remove existing @warn_unused_result attributes. @discardableResult should be added manually and deliberately to functions in stdlib and your own code. We'll be happy to clarify this behavior under "Impact on existing code" section.
————————————————————
@Jed,
> That said, the problem isn’t necessarily difficult to solve — it’s just that it’s important that it actually be solved at the same time the feature is rolled out.
I cannot speak for Apple, but judging from last Swift releases where SDKs were always up-to-date with latest Swift changes, I believe this change will be reflected as well.
The only place that inconsistencies may appear, are third-party libraries, but this has always been the case with all language changes.
Regards,
Adrian Kashivskyy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160317/5e67aa6d/attachment.html>
More information about the swift-evolution
mailing list