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

[Chris Lattner]

That makes sense to me.

-Chris

> On Dec 11, 2015, at 3:36 PM, Marc Knaup via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Related to this change it would be great when ignoring a closure returned by a function would become a warning instead of an error.
> 
>> On Sat, Dec 12, 2015 at 12:26 AM, Douglas Gregor via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>>> On Dec 10, 2015, at 4:49 PM, Dmitri Gribenko via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> On Thu, Dec 10, 2015 at 4:47 PM, Adrian Kashivskyy
>>> <adrian.kashivskyy at me.com> wrote:
>>>> I'm sure there are plenty of methods in Foundation that return a value which
>>>> can be ignored. However, as Joe noticed, such functions are generally in
>>>> minority.
>>>> 
>>>> I'd rather see a couple of `@allow_unused_result` than a dozen of
>>>> `@warn_unused_result`.
>>> 
>>> We are interested in seeing the actual data.
>> 
>> 
>> Indeed, this change has the potential to produce a huge number of warnings that would not be appreciated by the majority of Swift programmers. One can go ahead and hack the Swift compiler fairly easily and go build some apps to see just how often the warning fires. The place to change in the source is in
>> 
>> 	https://github.com/apple/swift/blob/master/lib/Sema/TypeCheckDecl.cpp
>> 
>> so that we always diagnose calls to non-Void functions. It should be an easy one-off change to gather data.
>> 
>> 	- Doug
>> 
>> 
>> 
>> _______________________________________________
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151211/5f9c71a9/attachment.html>