> On Feb 20, 2017, at 11:23 AM, Charles Srstka via swift-evolution
> <[email protected]> wrote:
>
>> On Feb 20, 2017, at 12:53 PM, Matthew Johnson <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>>
>>> On Feb 20, 2017, at 12:42 PM, Charles Srstka via swift-evolution
>>> <[email protected] <mailto:[email protected]>> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
