<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Without retracting any of the statements I made in my previous message:<div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170320/034336.html" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170320/034336.html</a></div><div class=""><br class=""></div><div class="">I'd like to point out that on a 1 to 10 scale of Swift past and potential changes that I'm passionate about – with a perfect 10 reserved for the Swift Ownership Manifesto and a 1 being something trivial like SE-0106 (Add a macOS Alias for the OSX Platform) – this issue rates around a 3 for me. I care but not a lot.</div><div class=""><br class=""></div><div class="">I'm mentioning this because a number of people on Twitter are commenting that discussion on this issue has gotten a little quarrelsome and I'm sorry if I've had a part in that. I only weighed-in to state that I have an opinion, not to draw a line in the sand and dig a bunker.</div><div class=""><br class=""></div><div class="">I'm fully aware that scoped access modifiers are basically an issue of aesthetics; allowing you to keep two entities that need interface-hiding in the same file, rather than in separate files. On that point, the whole issue could be seen as bike-shedding.</div><div class=""><br class=""></div><div class="">Further, even for my own "primary use case" that I personally gave here:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span><a href="https://gist.github.com/mattgallagher/b93c6e587488d60a68e4cc0318a7c356" class="">https://gist.github.com/mattgallagher/b93c6e587488d60a68e4cc0318a7c356</a></div><div class=""><br class=""></div><div class="">I can think of additional abstractions that would make the `private` members inaccessible while still keeping both View-Model and View-Binding in the same file e.g.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>a) Wrapping the `input` and `output` members in a generic wrapper that lives in another file (and so can take advantage of interface-hiding between files) and handles the required input-hidden/managed, output-exposed pattern</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>b) Building a series of libdispatch/reactive/whatever closures up in the `init` method that contain and self-manage the internallyMaintainedState – so it doesn't need to reside the View-Model at all – and merely store an opaque KeepAlive instance in the View-Model to anchor the lifetime</div><div class=""><br class=""></div><div class="">Involving more abstractions like this or setting up an opaque, self-managing entities does mean more work – both implementation time and conceptual gymnastics – but these approaches could deliver similar aesthetics without needing scoped access modifiers. There are potential performance implications involved in adding abstractions and closures but these can be handled as they arise.</div><div class=""><br class=""></div><div class="">Regards,</div><div class="">Matt Gallagher.</div><div class=""><br class=""></div></body></html>