I believe variables under private(set) can still be accessed with KVC (At least when the class inherits from nsobject.) On Thu, Dec 22, 2016 at 9:19 AM Andy Chou via swift-evolution < swift-evolution@swift.org> wrote:
> Point taken. I think Swift supports both styles reasonably well. Initially > it looked like writing the 'with' function would be troublesome but it > turned out to be quite simple. > > I appreciate the point you're making, which is that you get much of the > value of purely immutable values with Swift's mutable structures + value > semantics + let constant structs. And, you also get a simpler > implementation in some cases (e.g. not needing functions like 'with'). > > Swift has a pretty interesting model here that seems to capture some of > the best parts of the imperative and immutable/functional styles. For > example, I had to check whether this worked as expected: > > ``` > struct Person { > var name: String > var address: String > } > > class C { > private(set) var currentPerson = Person(name: "Andy", address: "1 > Battery St") > } > > func f() { > let instance = C() > instance.currentPerson.name = "Dave" // Cannot assign to property: > 'currentPerson' setter is inaccessible > } > ``` > > This means the implementation of class C can set the currentPerson and its > properties, but the currentPerson is immutable to the outside. A similar > thing could be accomplished with an immutable Person, but you still need to > use private(set), so it's no more complicated or risky to use the mutable > Person. > > The difference is mostly one of style, way of thinking, and psychology. > For some people seeing the declaration of Person having vars is > uncomfortable if they are used to a functional style. "If I have a Person, > will it be changed unexpectedly out from under me?" For people who know > Swift well, the fact that it's a struct means any potential change to > Person can only happen under controlled circumstances like an inout > parameter, and only if I declare it a var. This discussion was very helpful > for me to understand the nuances of struct better. > > Thanks, > > Andy > > On Dec 22, 2016, at 7:01 AM, Matthew Johnson <matt...@anandabits.com> > wrote: > > Yes, this is true. However, this thread is about improving the > convenience of immutable structs / functional code. It is quite common in > such code that the previous value is no longer needed. I am encouraging > people to focus on what the real benefits of this style is (value > semantics) and how the same benefit might be achieved in a different way in > a hybrid language like Swift. > > > _______________________________________________ > 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