[swift-evolution] [Pitch] Support for pure functions. Part n + 1.

[Joe Groff]

> On Feb 16, 2017, at 9:51 AM, Robert Widmann via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> 
>> On Feb 16, 2017, at 12:30 PM, Rien via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> In essence this is about assistance from the compiler that a function marked ‘pure’ is indeed pure?
>> I.e. an error message should be generated when a function marked as ‘pure’ is in fact not ‘pure’?
>> 
>> If the answer to both questions is ‘yes’ then -not surprising- its a -1 from me.
>> 
>> Unless there are other benefits?
> 
> This feature already exists in a certain sense - via the @effects annotation - but is undocumented, highly unstable, and does not entail any semantic checking.  I think that at least indicates a desire, even if it’s only in the lower-level parts of SIL now, to have some way to determine the “purity” of a function to perhaps guide an inliner or future block fusion pass.  Perhaps Andrew Trick can speak more about the goals of the annotation and whether it would be ready for prime time as it were.  

Effects is too low-level to be useful for much user code. It blindly applies LLVM attributes that are difficult for most Swift code to live up to. Any value type with refcounted fields immediately fails the "readnone" test even if it's semantically pure at the value semantics abstraction level. I think a higher-level 'pure' annotation like TJ is proposing, which fits into the value semantics model, is more useful as a user-facing feature, both as a reasoning tool and as an enabler for higher-level optimization.

-Joe