> On Feb 20, 2017, at 12:42 PM, Charles Srstka via swift-evolution > <swift-evolution@swift.org> wrote: > >> On Feb 20, 2017, at 10:55 AM, Michel Fortin via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
