[swift-evolution] Make non-void functions @warn_unused_result by default

David Owens II david at owensd.io
Wed Mar 2 15:38:27 CST 2016

Sure, but the token is intended to be used, that's why the API author returned it. What's the rationale you give to an API author on why would I mark that as discardable?

You gave two contexts in which the result can either be discarded or should be kept. How does the API author know which context you are using? How does the compiler?

let _ = NSNotificationCenter.defaultCenter.addObserverForName(...)



The first version is explicitly saying, "yes, I know the API author is given me back something I may need but I know I don't". 
The second version isn't saying anything about the return value.

Had the API been marked as discardable, there's no way to tell if you've made an oversight error or were being explicit about not needing the result.


> On Mar 2, 2016, at 1:25 PM, Jeff Kelley <slaunchaman at gmail.com> wrote:
> There are plenty of APIs that return an opaque object, like a token, that isn’t always needed. Consider NSNotificationCenter’s addObserverForName(_:object:queue:usingBlock:) method; it returns an opaque NSObject to act as the observer. If you’re adding an observer that lasts the lifetime of your application, you may not need to do anything with the observer, and so you might not use the return value. Other times, for short-lived observers, you’d save that reference so you could call removeObserver(_:) with it.
> Jeff Kelley
> SlaunchaMan at gmail.com <mailto:SlaunchaMan at gmail.com> | @SlaunchaMan <https://twitter.com/SlaunchaMan> | jeffkelley.org <http://jeffkelley.org/>
>> On Mar 2, 2016, at 4:21 PM, David Owens II via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> Swift's error handling model is optional -> throws -> runtime error. Returning a result is perfectly acceptable as a return value.
>> And what information are you returning from your side-effect methods that you shouldn't be using? That's what I'm having a hard time trying to grok - the actual use case.
>> -David
>>> On Mar 2, 2016, at 1:18 PM, Dmitri Gribenko <gribozavr at gmail.com <mailto:gribozavr at gmail.com>> wrote:
>>> On Wed, Mar 2, 2016 at 1:16 PM, David Owens II via swift-evolution
>>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> On Mar 2, 2016, at 12:20 PM, Erica Sadun <erica at ericasadun.com <mailto:erica at ericasadun.com>> wrote:
>>>> This proposal argues that while this workaround makes it clear that the
>>>> consumption of the result is intentionally discarded, it offers no traceable
>>>> intent as to whether the API designer meant for this use to be valid.
>>>> Forcing an attribute ensures the discardable return value use is one that
>>>> has been considered and approved by the API author.
>>>> But what does this really mean? As an API author, when do I actually mark
>>>> something as being discardable? Discarding the result is as much about the
>>>> context in which the API is being used as to the intent the original author
>>>> had for it.
>>> When it makes sense to call your method just for side-effects.
>>> If you have error handling information, use 'throw', don't use return values.
>>> Dmitri
>>> -- 
>>> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
>>> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com <mailto:gribozavr at gmail.com>>*/
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto: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/20160302/bb01c41c/attachment.html>

More information about the swift-evolution mailing list