[swift-evolution] "with" operator a la O'Caml?

[Derrick Ho]

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 at 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 <matthew at 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 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/20161222/132ea1f9/attachment.html>