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

[Matthew Johnson]

> On Feb 20, 2017, at 1:42 PM, Michel Fortin <michel.fortin at michelf.ca> wrote:
> 
>> Le 20 févr. 2017 à 14:23, Charles Srstka <cocoadev at charlessoft.com> a écrit :
>> 
>> I’m not sure how I feel about that, since it hamstrings the ability to improve APIs in a lot of ways without breaking backwards compatibility. A quick example off the top of my head would be all the Cocoa APIs that started out having ivars representing paths backed by simple getter methods, and were later refactored to be URL-based, but with the original path properties become computed properties pointing to the URL’s “path” property. With this, properties would not be able to be refactored in this way unless the library developer had previously declared the “path” property as private(set), which is unlikely for a property that was not intended to be changed after the class was initialized.
> 
> Version 1:
> 
> 	public class A {
> 		public let path: String
> 	}
> 
> Version 2:
> 
> 	public class A {
> 		public pure var path: String { return url.path }
> 		public let path: URL
> 	}
> 
> This is assuming `let` is implicitly pure. It probably should not be. Or at least it should not when crossing module boundaries. Note that internal to the module it wouldn't violate any contract to allow pure code access to `let` variables.
> 
> Which makes me think of an idea: internal to the module, `pure` could be inferred for everything. Only the published APIs would require the annotations, and only if you want `pure` to be part of the API contract. Attaching `pure` to an internal function could still be useful for your own reasoning though.

That’s a very interesting approach that could lighten the syntactic load.  We could strategically annotate our code where we want purity verified, but otherwise omit the annotation for members that don’t need to be visible outside the module.  This approach works especially well for closures.  I like it a lot!

> 
> -- 
> Michel Fortin
> https://michelf.ca
>