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

Michel Fortin michel.fortin at michelf.ca
Thu Jan 14 06:22:38 CST 2016

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.

Michel Fortin

More information about the swift-evolution mailing list