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

[David Sweeris]

> On Feb 20, 2017, at 11:23 AM, Charles Srstka via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Feb 20, 2017, at 12:53 PM, Matthew Johnson <matthew at anandabits.com <mailto: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:
>>> 
>>> 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.

My understanding is that this particular nuance — a “let” being semantically different from a “var that for whatever reason can’t be set by you" — has pretty much been the case since the beginning... it just doesn’t come up much. Come to think of it, I don’t even know if Apple's Swift Book mentions it (probably should, if it doesn’t).

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