[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