<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=""><div class="">Hi Tony</div><div class=""><br class=""></div>Personally, I find my solution much better because everything <div class="">of a class struct definition stays together in one place,</div><div class="">instead of being scattered over multiple extensions, wich btw, </div><div class="">can be placed anywhere, that is, not necessarily within </div><div class="">the same source file.. (no doubt that is what some people are </div><div class="">going to do… Also, Imho, this is not the right purpose of extensions. </div><div class="">Extension are primary meant for users of classes/structs, clearly, </div><div class="">as the name implies, to extend these, while keeping the original </div><div class="">class/structs intact and hidden from those users, if desired. </div><div class="">So I’d would consider this being a bad bad programming practice, sorry. </div><div class="">Btw. I’d prefer subclassing instead of extensions, however</div><div class="">this is not possible with structs... </div><div class=""><div class=""><br class=""></div><div class="">Costs? Of, course there are implications, but that is the consequence </div><div class="">with every change to a programming language, with all the aspects </div><div class="">you have described below. </div><div class="">However, this is not a source changing feature, which should be not so </div><div class="">difficult to implement, completely optional, and almost trivial to use also for starters.</div><div class=""><br class=""></div><div class="">TedvG</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 20. Jun 2017, at 18:06, Tony Allevato <<a href="mailto:tony.allevato@gmail.com" class="">tony.allevato@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, Jun 20, 2017 at 8:57 AM Ted F.A. van Gaalen <<a href="mailto:tedvgiosdev@gmail.com" class="">tedvgiosdev@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">Hi Tony </div><div class="">I don’t think so, then I would have to split my class up into extensions, </div><div class="">not really workable I’d say.</div></div></blockquote><div class=""><br class=""></div><div class="">Why not?</div><div class=""><br class=""></div><div class="">What makes this workable:</div><div class=""><br class=""></div></div></div></div></blockquote>btw, internal: can be omitted here: <br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class="">struct MyType {</div><div class=""> internal:</div><div class=""> var</div><div class=""> var</div><div class=""> var</div><div class=""> public:</div><div class=""> func</div><div class=""> func</div><div class=""> private:</div><div class=""> func</div><div class=""> func</div><div class="">}</div><div class=""><br class=""></div><div class="">but this not workable?</div><div class=""><br class=""></div><div class="">struct MyType {</div><div class=""> var</div><div class=""> var</div><div class=""> var</div><div class="">}</div><div class="">public extension MyType {</div><div class=""> func</div><div class=""> func</div><div class="">}</div><div class="">private extension MyType {</div><div class=""> func</div><div class=""> func</div><div class="">}</div><div class=""><br class=""></div><div class="">I don't see what's so bad about the latter example. It's just a different syntax for what you're asking to do, except that it's already in the language.</div><div class=""><br class=""></div><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""> it would be an optional feature anyway. so one can still build classes</div><div class="">like it is now, no problem. </div><div class="">I would like in-line scope designators *within* extensions as well.</div></div></blockquote><div class=""><br class=""></div><div class="">Every optional feature proposed to be added to the language has costs associated with it—design time, implementation time, cognitive load on people learning the language—so what I'm trying to determine is benefits this would add to justify that cost. Since this can effectively be achieved today with extensions (again, with the exception of stored properties, which should be fixed separately and then that exception goes away), I'm curious about what you think is missing here.</div><div class=""><br class=""></div><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">Regards</div><div class="">TedvG.</div><div class=""><br class=""></div><div class="">more below inline</div><br class=""><div class=""></div></div><div style="word-wrap:break-word" class=""><div class=""><blockquote type="cite" class=""><div class="">On 20. Jun 2017, at 17:10, Tony Allevato <<a href="mailto:tony.allevato@gmail.com" target="_blank" class="">tony.allevato@gmail.com</a>> wrote:</div><br class="m_966929897020629792Apple-interchange-newline"><div class=""><div dir="ltr" class="">You can already effectively have these "regions" using extensions, with the exception of stored properties since they can't be placed there.<div class=""><br class=""></div><div class="">struct MyType { ... }</div><div class="">public extension MyType { ... }<br class=""></div><div class="">private extension MyType { ... }</div><div class=""><br class=""></div><div class="">Once stored properties are allowed in extensions (IIRC supporting that within the same file as the type declaration is something the core team has said is reasonable?), you could do this there as well. Is this not sufficient for what you want to do?</div><div class=""><br class=""></div><div class="">Since there are already two ways of specifying the visibility of a type member (preceding the type itself, or using the default visibility of the declaring extension), I'd be wary of adding a third.</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Mon, Jun 19, 2017 at 10:57 PM Rien via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I don’t like this, it violates the locality principle. I.e. that all information that is needed to understand something is close by.<br class=""></blockquote></div></div></blockquote></div></div><div style="word-wrap:break-word" class=""><div class=""> well, what then if you use parts of your program defined in other sources, protocols … etc. ? </div><div class="">met vriendelijke groeten</div><div class="">TedvG</div></div><div style="word-wrap:break-word" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="">
But since it is not something that everybody has to use… I don’t object to it either.<br class="">
<br class="">
Regards,<br class="">
Rien<br class="">
<br class="">
Site: <a href="http://balancingrock.nl/" rel="noreferrer" target="_blank" class="">http://balancingrock.nl</a><br class="">
Blog: <a href="http://swiftrien.blogspot.com/" rel="noreferrer" target="_blank" class="">http://swiftrien.blogspot.com</a><br class="">
Github: <a href="http://github.com/Balancingrock" rel="noreferrer" target="_blank" class="">http://github.com/Balancingrock</a><br class="">
Project: <a href="http://swiftfire.nl/" rel="noreferrer" target="_blank" class="">http://swiftfire.nl</a> - An HTTP(S) web server framework in Swift<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
> On 17 Jun 2017, at 23:48, Ted F.A. van Gaalen via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" 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="">
> private var roofTiles = 11201<br class="">
> 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="">
> init(..) {.. }<br class="">
> private: // <—— In-line scope modifier all following declarations are private here.<br class="">
> var rooms = 5<br class="">
> var roofTiles = 11201<br class="">
> 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" target="_blank" class="">swift-evolution@swift.org</a><br class="">
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class="">
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</blockquote></div>
</div></blockquote></div></div></blockquote></div></div>
</div></blockquote></div><br class=""></div></div></body></html>