> On Feb 20, 2017, at 1:23 PM, Charles Srstka <[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: >>> >>>> On Feb 20, 2017, at 10:55 AM, Michel Fortin via swift-evolution >>>> <[email protected] <mailto:[email protected]>> 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?
If calling code can’t see it, it also can’t access it. It can only be reached through a different member of the struct. That member would need to be pure. That is where it would be enforced. > >>>> 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. Computed read-only properties could be `pure`. If the refactoring was able to preserve this purity it shouldn’t be a breaking change (with respect to purity at least). Stored `var` properties of a class would never be pure. > > Charles
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
