<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="">Hi Robert,<div class=""><br class=""><div class="">This would be an optional feature, can be left out. </div><div class="">if one doesn’t use it nothing changes.</div><div class="">Although imho it looks better, the primary intent</div><div class="">is to hide/protect members, be it vars, functions,</div><div class="">from outside access, without having to type scope</div><div class="">qualifiers on most of my source lines.</div><div class="">As you can see, personally I use vertical space a lot:</div><div class="">brackets on new lines, empty lines, etc.</div><div class="">I use a Mac Mini with a a 4K screen and a relative small font</div><div class="">(and reading glasses :o) thus having to scroll very little.</div><div class=""><br class=""></div><div class="">Kind Regards</div><div class="">TedvG</div><div class=""><br class=""></div><div class=""> </div><div class=""> <br class=""><div><blockquote type="cite" class=""><div class="">On 19. Jun 2017, at 20:45, Robert Bennett <<a href="mailto:rltbennett@icloud.com" class="">rltbennett@icloud.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">+1 for member variables, -1 for member functions. Functions take up too much vertical space to make this convenient; you’d constantly be scrolling around to view or modify the access level of a function. Plus I tend to group functions by use — private functions go directly above the public function that calls them. But member declarations are often one or just a few lines, and additionally are often grouped by access level anyway (at least that’s how I do it) so this provides a compact way to group them.<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Jun 17, 2017, at 5:48 PM, Ted F.A. van Gaalen via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">(I am not sure if I should tag this subject with [pitch]? ) <br class=""><br class="">Please don’t worry , I am not attempting to start a new<br class="">and infinite thread about whether or not the way scope<br class="">is handled in Swift is imho correct or not.<br class="">Errhm well, apart from that “protected” is missing,<br class="">but please let us not start again.. :o) <br class=""><br class="">No, it is more or less a convenience solution to<br class="">prevent unnecessary wear and tear to the following keys<br class="">on my keyboard: [ A,E, I, P, R, T, V]<br class=""><br class="">I prefer it, not to expose those class or struct members<br class="">which should not be accessible outside the class or struct<br class=""><br class="">Currently, to prevent access to private Items,<br class="">I have to type the word “private” too many times:<br class=""><br class="">class House<br class="">{<br class=""> private var rooms = 5<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>private var roofTiles = 11201<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>private let paint = UIColor.Blue;<br class=""> private var yearTax: Money = “323,56"<br class=""> private let garageVolume = 60.0<br class=""><br class=""> init(..) {.. }<br class=""><br class=""> private func calculateTax() {...}<br class=""><br class=""> public func roomsUnoccupied() -> Int {…}<br class=""><br class=""> func roofData(……) {…}<br class=""><br class=""> private func a{…} <br class="">}<br class=""><br class="">To set the scope of a list of members I suggest the<br class="">“in-line scope modifiers” (anyone with a better name for it?) <br class=""><br class="">For example if one has a source line containing the word<br class="">“private:” then all the following member declarations will<br class="">be “private” until another inline scope modifier is encountered<br class="">with one “default scope” to escape from it. like in the following example”<br class=""><br class="">The compiler can detect that it is an inline scope modifier, because it ends with a colon<br class=""><br class="">“Normal” scope modifiers, that is the ones which precede the member’s name <br class="">directly should imho not be allowed within such a scope block.<br class="">unless they would override for that specific item, but that looks ugly. <br class=""><br class="">getter & setters and init should appear in default scope<br class="">(or with no in-line scope modifiers)<br class=""><br class="">Inline scope modifiers can be specified as often as<br class="">desired and in arbitrary sequence. <br class=""><br class=""><br class="">class House<br class="">{<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span> init(..) {.. } <br class=""> private: // <—— In-line scope modifier all following declarations are private here.<br class=""> var rooms = 5<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span> var roofTiles = 11201<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span> let paint = UIColor.Blue;<br class=""> var yearTax: Money = “323,56"<br class=""> func calculateTax() {…}<br class=""> func a{…} <br class=""><br class=""> public: // <—— In-line scope modifier<br class=""> var garageVolume = 60.0 <br class=""> func roomsUnoccupied() -> Int {…}<br class=""> func roofData(……) {…}<br class=""><br class=""> defaultscope: // <—— Return to default scope (only needed when preceding inline scope modifiers are present. )<br class=""><br class=""> func sellHouse(buyer: CustomerID) <br class="">}<br class=""><br class="">See? looks a lot better, don’t you think so? <br class="">it also makes sources more readable because one can <br class="">now conveniently group items.<br class=""><br class="">100% source compatible with whatever scope <br class="">mechanism now or in the future is or will be deployed.<br class=""><br class=""><br class="">(The idea is not exactly new, a similar construct is available in Object Pascal.) <br class=""><br class="">?<br class=""><br class="">Kind Regards<br class="">TedvG<br class=""><br class=""><br class=""><br class=""><br class=""><br class=""><br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></blockquote><br class=""></div></div></blockquote></div><br class=""></div></div></body></html>