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

[Chris Lattner]

> On Feb 24, 2016, at 3:45 PM, Janosch Hildebrand via swift-evolution <swift-evolution at swift.org> wrote:
> 
> No worries, there should be plenty of time for discussion.
> 
> Swift 3 contains many changes that will require libraries to be updated anyway, so I don’t think this would prove to be an undue burden.

Agreed - source breaking changes in Swift 3 are already a given, so we’re going to provide a really great migrator to help move people forward.  Beyond Swift 3, the Swift community will be a much more diverse place with multiple platforms supported and more diverse tools/ide’s used.

As such, source breaking changes will be much more difficult to justify after Swift 3 is out the door, we’re prefer to roll them into Swift 3 where ever possible.

-Chris


> But yes, weighing cost vs. benefit will certainly be part of the proposal evaluation.
> 
> As for whom we want to help, it’s predominantly API users.
> Ideally every function would be perfectly annotated but ultimately not every API developer will know about, remember or put in the effort to annotate with @warn_unused_result. Making the inverse the default should hopefully be “safer” by warning by default.
> 
> Extraneous warnings are also much more obvious than missing warnings, encouraging potential annotation.
> 
> The expectation that many if not most functions (with return values) should warn is, I believe, mostly motivating in the sense of hopefully making this change (more) palatable.
> 
> - Janosch
> 
>> On 24 Feb 2016, at 23:47, Gwendal Roué <gwendal.roue at gmail.com> wrote:
>> 
>> Oh yes please, don't rush on this...
>> 
>> Who do we want to help here? API users, or API developers?
>> 
>> Considering that Swift may be on the verge of a great breakthrough, plenty of immature yet popular libraries will ship. Plenty have already shipped. This is a great sign of vitality. Should @warn_unused_result become the default, the quality of the code of the users of those libraries risks a brutal degradation, full of poor `let _ = ...`.
>> 
>> Gwendal
>> 
>>> Le 24 févr. 2016 à 16:01, Jean-Daniel Dupas via swift-evolution <swift-evolution at swift.org> a écrit :
>>> 
>>> IMHO, before any decision, it may be interesting to write a quick patch and run the modified compiler on real code to see how much false positive it would generate.
>>> 
>>>> Le 24 févr. 2016 à 16:13, Janosch Hildebrand via swift-evolution <swift-evolution at swift.org> a écrit :
>>>> 
>>>> Erica's proposal about "Modernizing Attribute Case and Attribute Argument Naming" made me remember this discussion.
>>>> 
>>>> I don't think a proposal was ever submitted? If no one else is working on a proposal already I would offer myself up for writing this up.
>>>> 
>>>> - Janosch
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution