<div dir="ltr">to sum up. so far the feedback on this proposal was:<div><br></div><div>1) generally in favour (e.g. to have ability of adding variables and accessing privates at all)</div><div><br></div><div>2) the name &quot;continuation&quot; is used for something else</div><div><br></div><div>3) why not to use partials as they are in c#</div><div><br></div><div>4) having explicit names for continuations is unwanted because naming is hard</div><div><br></div><div>5) the ledger list is unnecessary as anyone on the same module will be able to change it anyway - false feel of protection.</div><div><div><br></div></div><div class="gmail_extra">here are my thoughts on it.</div><div class="gmail_extra"><br></div><div class="gmail_extra">1) &quot;generally in favour (e.g. to have ability of adding variables and accessing privates at all)&quot;</div><div class="gmail_extra">-- great! thank you.</div><div class="gmail_extra"><br></div><div class="gmail_extra">2) &quot;the name &quot;continuation&quot; is used for something else&quot;</div><div class="gmail_extra">-- thought the same. let it be &quot;part&quot; instead of continuation</div><div class="gmail_extra"><br></div><div class="gmail_extra">3) &quot;why not to use partials as they are in c#&quot;</div><div class="gmail_extra">-- my belief here is that just because i made my type partial (for my own reasons, e.g. as a result of splitting a single-file class into a multi-file) it does not necessarily mean I want other developers of my team (on the same module) to add continuations / parts to my class. in other words, while there are the module boundaries (the building walls) i still want to see some partitions between the rooms of that building to have some privacy.</div><div class="gmail_extra"><br></div><div class="gmail_extra">4) &quot;having explicit names for continuations is unwanted because naming is hard&quot;</div><div class="gmail_extra">-- every time I am adding extension now I want to label it somehow to indicate it&#39;s purpose. if that extensions adds a protocol conformance (e.g. &quot;extension ViewController: UITableViewDataSource&quot;) the problem is not as critical as the protocol (or the list of protocols) name itself can serve the purpose of such an indication. if there is no such a protocol conformance however i tend to add a &quot;MARK: ThePurpose&quot; or a comment (&quot;extension ViewController /* ThePurpose */) and as the comments are not checked and get out of sync every time i do this i wish there was a a more explicit extension label in the language for this purpose. maybe that&#39;s just me.</div><div class="gmail_extra"><br></div><div class="gmail_extra">5) &quot;the ledger list is unnecessary as anyone on the same module will be able to change it anyway - false feel of protection.&quot;</div><div class="gmail_extra">-- to this i can give the same response as in (3). here is another example that hopefully will clarify my point: we shall not really say that &quot;private&quot; in swift is useless and &quot;internal&quot; shall be used instead of it just because anyone in the same module can bypass it anyway: go to your class and change the source from &quot;private&quot; to &quot;internal&quot; for their own benefits, so why bother with private / fileprivate to begin with. so is true in regards to the ledger: yes, it is true that anyone on the team working on the same module has a physical ability to go to my class (the class who&#39;s sole maintainer and &quot;owner&quot; is myself) and mess around it, changing it&#39;s ledger along the way, or making it partial as in (3) or changing it&#39;s privates to internal, or adding variables, etc. it&#39;s just they shouldn&#39;t, at least not talking to me first. they won&#39;t be &quot;behaving properly&quot; if they do.</div><div class="gmail_extra"><br></div><div class="gmail_extra">some additional thoughts. ledger works similar to the c++ class definition itself, which lists all the members of the class, just on a less granular scope: while in C++ you have to go there every time you want to add, say, a private method, with parts you go change the ledger very infrequently, to add a group or functionalities. another tangentially similar feature of C++ is &quot;friends&quot;. if you class have, say, 10 different extensions each implementing a certain feature and you converted them to &quot;parts&quot; the ledger list will contain 10 entries naming those features explicitly.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Mike</div><div class="gmail_extra"><br></div><div class="gmail_extra">ps. by now i figured that discussing protection levels in swift is akin to having a wonderful morning walk across a mine field</div><div class="gmail_extra"><br></div></div>