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

Kametrixom Tikara kametrixom at icloud.com
Fri Dec 11 00:23:57 CST 2015


I think we actually have two things colliding here: Think about it, why would we need a @suppress_unused_result attribute? Because of side effects! That's the only reason we would ever need to have this attribute. Now we already have the @effects(readnone) attribute to enable optimizations for pure functions. Now we can combine both of those into one: @pure. This attribute does this:
- It indicates that the function is purely functional (= no side-effects, same result for same input)
- It implicitly adds the @effects(readnone) attribute to enable such optimizations
- It implicitly adds the @warn_unused_result attribute

To make sure that the function actually is pure we need to check that every called function within is pure itself and no external variables get accessed.

Now the only thing to do is to make the compiler implicitly add the @pure keyword where the conditions are satisfied.

Something I haven't thought about yet: Not being able to read external variables (@effects(readonly)) are also functions without side effects, but they're not pure, since the result doesn't have to be the same for the same input. I don't want to suggest another keyword for that (we have too many already) but I believe this is actually what we want here.

Let me know what you think, FP ftw

– Kame

> On 11 Dec 2015, at 02:31, Chris Lattner 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.
> 
> FWIW, if there was a widespread problem, we could have the importer slap @suppress_unused_result on all imported decls (at least, ones that didn’t have the clang warn_unused_result attribute).
> 
> This would allow swift code to have the “right” default policy without causing a ton of noise from imported APIs.
> 
> -Chris
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution


More information about the swift-evolution mailing list