[swift-evolution] [Pitch] Support for pure functions. Part n + 1.
Matthew Johnson
matthew at anandabits.com
Mon Feb 20 12:53:18 CST 2017
> On Feb 20, 2017, at 12:42 PM, Charles Srstka via swift-evolution <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.
>
>> 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).
>
> Charles
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170220/b8f8e38d/attachment.html>
More information about the swift-evolution
mailing list