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

[Charles Srstka]

> On Feb 20, 2017, at 12:53 PM, Matthew Johnson <matthew at anandabits.com> wrote:
> 
>> 
>> On Feb 20, 2017, at 12:42 PM, Charles Srstka via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> On Feb 20, 2017, at 10:55 AM, Michel Fortin via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> a) Structs/Locals:
>>> Structs and local variables behave similarly. You can access `let` and `var` properties and mutate the later.
>> 
>> What if the struct contains class ivars, including private ones that you may not know about but nonetheless get accessed as a side effect of accessing the struct’s “var” properties?
> 
> You should be able to access them in accordance with the restrictions on using classes in a pure manner.

How can those restrictions be enforced, if the class is a private internal property of the struct that the calling code can’t see?

>>> b) Classes:
>>> You can't access the variables of a class in a pure function. But you can access its `let` properties. That's because as long as there is no `var` in the dereferencing path, you are guarantied to be accessing a constant. In classes, `let` properties are thus implicitly pure; stored `var` properties are not. Which means that pure instance methods on classes can only access `let` properties, in addition to computed properties that are themselves `pure` and other `pure` methods.
>> 
>> What if the “let” property becomes a “var” property in a future version of the library you’re linking against?
> 
> That would be a breaking change if the `let` was public or if any `pure` public methods were accessing it (unless they were refactored to not rely on it anymore).

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.

Charles

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170220/e0db41df/attachment.html>