> Le 20 févr. 2017 à 13:42, Charles Srstka <[email protected]> a écrit : > >> On Feb 20, 2017, at 10:55 AM, Michel Fortin via swift-evolution >> <[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 can look at the value of the pointer to that class instance (you can convert that pointer to a hex value and return it as a string if you want), but if you dereference the pointer you need to follow the rules for classes. If you call any accessor (because the type is opaque or for other reasons), those accessors must be pure (and thus follow the same rules). >> 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's an interesting question. Either `let` provides purity guaranties implicitly (as I was suggesting), or it needs to be annotated `pure` in order to provide those guaranties. The later would allow changing a `let` to a `var` in a future version of a library without breaking clients. And you could also change a `pure let` to a `pure var`. Perhaps being explicit is better. In the end, it depends on how resilience works for `let`. -- Michel Fortin https://michelf.ca _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
