[swift-evolution] [Proposal idea] Support for pure functions

[Joe Groff]

> On Jan 14, 2016, at 4:22 AM, Michel Fortin via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Le 14 janv. 2016 à 3:25, Andrew Bennett <cacoyi at gmail.com> a écrit :
> 
>> Very interesting points Andy, I think I agree with pretty much everything you've said. 
>> 
>> Good point on `func foo<T>(t: T) {}` being impure without a type constraint, deinit seems to have some interesting consequences.
>> 
>> I've been throwing around the idea of having this notation:
>> func myFunc<T,U>(value: T, apply: T -> U) @pure(apply) -> U
>> to indicate that myFunc is pure if 'apply' is also pure. Similar to @rethrows.
>> 
>> If it also requires that A has a pure deinit, or further requirements, then perhaps you could use "@pure(value,apply)". In your case you would annotate it like this:
>> func foo<T>(t: T) @pure(t) {}
>> 
>> Then the compiler can make foo pure only if T's `deinit` is marked @pure. The issue there is, as you say, if T can be subclassed then those need @pure deinit. This could be solved if the annotation is always inherited, likewise for overrides.
> 
> In D, for template functions, the pure attribute is deduced from the function's body. It'd be nice to have deduced purity so you don't have to figure out those conditional purity requirements for every function. 
> 
> Deduced purity should probably not extend automatically to other resilience domains though, because it provides a guaranty that might not apply to future versions of that function. So you still need a way to annotate.

Deducing purity from function bodies is compile-time expensive and brittle, and impossible across resilience boundaries. It wouldn't work well with our non-instantiation-based generics model.

-Joe