<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="">I tend to disagree with this whole concept of access modifiers; what we have today is at least somewhat sane and consistent across all constructs.</div><div class=""><br class=""></div><div class="">As for your example, if other code within your file is leveraging these “private” pieces, doesn’t that suggest that your API model is already wrong? After all, those pieces wouldn’t be used if they weren’t needed. I’m also hard pressed to believe that this is solving a problem that isn’t purely academic.</div><div class=""><br class=""></div><div class="">I’d actually prefer the opposite extreme: I want everything public unless it’s prefixed with an _. To me, the _ prefix adds significantly more contextual awareness that I’m venturing into parts of the construct that are not intended for general use. It has the add benefit that it makes these types of uses grepable within the codebase so audits are quite trivial.</div><div class=""><br class=""></div><div class="">&nbsp; &nbsp; struct F {</div><div class="">&nbsp; &nbsp; &nbsp; &nbsp; func _privateUsage() {}</div><div class="">&nbsp; &nbsp; &nbsp; &nbsp; func publicUsage() {}</div><div class="">&nbsp; &nbsp; }</div><div class=""><br class=""></div><div class="">Right now, I find having to prefix nearly everything with public is extremely annoying.</div><div class=""><br class=""></div><div class="">Humorously enough, I’m actually running into issues with this right now. I’m looking into fixing some of the NSNumber functionality in corelib and the fact that some of the internal state is marked as private means it’s not readably testable nor easy to inspect to validate is doing the right thing.</div><div class=""><br class=""></div><div class="">-David</div><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 5, 2015, at 9:04 PM, Nikolai Vazquez via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="markdown-here-wrapper" style=""><p style="margin:0px 0px 1.2em!important" class="">I agree that there should be an access level that hides implementation details from other types in the same file. However, it shouldn’t replace <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);border-radius:3px;display:inline;background-color:rgb(248,248,248)" class="">private</code>, because 1) helper types might benefit from <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);border-radius:3px;display:inline;background-color:rgb(248,248,248)" class="">private</code> elements and 2) like you said, backwards compatibility.</p><p style="margin:0px 0px 1.2em!important" class="">On Sat, Dec 5, 2015 at 11:40 PM Ilya via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>&gt; wrote:</p><div style="margin: 0px 0px 1.2em !important;" class=""><br class="webkit-block-placeholder"></div><div class="markdown-here-exclude"><div class=""><br class="webkit-block-placeholder"></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">I think the it would help a great deal to have an access level modifier that is really private and visible only inside the class itself. Right now, the only way to hide implementation details for a class is to hide the class code in a separate file, which is very inconvenient for several reasons:<div class=""><br class=""></div><div class="">1) the meaning of the code changes depending on which file the class is in. It's very easy to accidentally expose class internal details and then call class elements that are meant to be used only inside the class. Having a keyword for class internals will allow the compiler to ensure that only the public API for the class is used from the outside world. The user can check types on his own, but it's better that the compiler does it automatically. Similarly, the user can check that only the proper APIs are called, but it's better that the compiler does it automatically.</div><div class=""><br class=""></div><div class="">2) accessibility by file structure may cause some really short files.&nbsp;</div><div class=""><br class=""></div><div class="">3) It's impossible to group related classes in one file but still hide implementation details inside each class</div><div class=""><br class=""></div><div class="">I think that it the best solution is to make private keyword do what it states -- keep the class element private to the class. But if it's really important to have a separate keyword for backward compatibility, it would be the next best thing.</div><div class=""><br class=""></div><div class="">--</div><div class="">Ilya Belenkiy</div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=ehkPrOqsls0Av8wq-2BERvskItOl-2FsoKM25PE-2F6JNHyRP4Mo0spxvYywSQWqUaJEgCwgLZNg6H81aCHtuLVaMwHDi3XKFdJoJrE8Is5W4Gcc-2BE8VwOwNmvWhWE6D7-2Fbv910ANEwH4q8AN-2B09ozksEE7nYeJJwZATPTMIunAulRltfJhjMBdpVH20dYqfDEc0M303DcgRVyK58Ht24-2B6Jb24hXpkD1vpFDW3cPmXBQgDvI-3D" alt="" width="1" height="1" border="0" style="min-height: 1px !important; width: 1px !important; border-width: 0px !important; margin: 0px !important; padding: 0px !important; display: none !important;" 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 class=""><br class="webkit-block-placeholder"></div></div><div style="margin: 0px 0px 1.2em !important;" class=""><br class="webkit-block-placeholder"></div>
<div title="MDH:SSBhZ3JlZSB0aGF0IHRoZXJlIHNob3VsZCBiZSBhbiBhY2Nlc3MgbGV2ZWwgdGhhdCBoaWRlcyBp
bXBsZW1lbnRhdGlvbiBkZXRhaWxzIGZyb20gb3RoZXIgdHlwZXMgaW4gdGhlIHNhbWUgZmlsZS4g
SG93ZXZlciwgaXQgc2hvdWxkbid0IHJlcGxhY2UgYHByaXZhdGVgLCBiZWNhdXNlIDEpIGhlbHBl
ciB0eXBlcyBtaWdodCBiZW5lZml0IGZyb20gYHByaXZhdGVgIGVsZW1lbnRzIGFuZCAyKSBsaWtl
IHlvdSBzYWlkLCBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eS48ZGl2Pjxicj48ZGl2IGNsYXNzPSJn
bWFpbF9xdW90ZSI+PGRpdiBkaXI9Imx0ciI+T24gU2F0LCBEZWMgNSwgMjAxNSBhdCAxMTo0MCBQ
TSBJbHlhIHZpYSBzd2lmdC1ldm9sdXRpb24gJmx0OzxhIGhyZWY9Im1haWx0bzpzd2lmdC1ldm9s
dXRpb25Ac3dpZnQub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3dpZnQtZXZvbHV0aW9uQHN3aWZ0Lm9y
ZzwvYT4mZ3Q7IHdyb3RlOjxicj48L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUi
IHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRk
aW5nLWxlZnQ6MWV4Ij48ZGl2IGRpcj0ibHRyIj5JIHRoaW5rIHRoZSBpdCB3b3VsZCBoZWxwIGEg
Z3JlYXQgZGVhbCB0byBoYXZlIGFuIGFjY2VzcyBsZXZlbCBtb2RpZmllciB0aGF0IGlzIHJlYWxs
eSBwcml2YXRlIGFuZCB2aXNpYmxlIG9ubHkgaW5zaWRlIHRoZSBjbGFzcyBpdHNlbGYuIFJpZ2h0
IG5vdywgdGhlIG9ubHkgd2F5IHRvIGhpZGUgaW1wbGVtZW50YXRpb24gZGV0YWlscyBmb3IgYSBj
bGFzcyBpcyB0byBoaWRlIHRoZSBjbGFzcyBjb2RlIGluIGEgc2VwYXJhdGUgZmlsZSwgd2hpY2gg
aXMgdmVyeSBpbmNvbnZlbmllbnQgZm9yIHNldmVyYWwgcmVhc29uczo8ZGl2Pjxicj48L2Rpdj48
ZGl2PjEpIHRoZSBtZWFuaW5nIG9mIHRoZSBjb2RlIGNoYW5nZXMgZGVwZW5kaW5nIG9uIHdoaWNo
IGZpbGUgdGhlIGNsYXNzIGlzIGluLiBJdCdzIHZlcnkgZWFzeSB0byBhY2NpZGVudGFsbHkgZXhw
b3NlIGNsYXNzIGludGVybmFsIGRldGFpbHMgYW5kIHRoZW4gY2FsbCBjbGFzcyBlbGVtZW50cyB0
aGF0IGFyZSBtZWFudCB0byBiZSB1c2VkIG9ubHkgaW5zaWRlIHRoZSBjbGFzcy4gSGF2aW5nIGEg
a2V5d29yZCBmb3IgY2xhc3MgaW50ZXJuYWxzIHdpbGwgYWxsb3cgdGhlIGNvbXBpbGVyIHRvIGVu
c3VyZSB0aGF0IG9ubHkgdGhlIHB1YmxpYyBBUEkgZm9yIHRoZSBjbGFzcyBpcyB1c2VkIGZyb20g
dGhlIG91dHNpZGUgd29ybGQuIFRoZSB1c2VyIGNhbiBjaGVjayB0eXBlcyBvbiBoaXMgb3duLCBi
dXQgaXQncyBiZXR0ZXIgdGhhdCB0aGUgY29tcGlsZXIgZG9lcyBpdCBhdXRvbWF0aWNhbGx5LiBT
aW1pbGFybHksIHRoZSB1c2VyIGNhbiBjaGVjayB0aGF0IG9ubHkgdGhlIHByb3BlciBBUElzIGFy
ZSBjYWxsZWQsIGJ1dCBpdCdzIGJldHRlciB0aGF0IHRoZSBjb21waWxlciBkb2VzIGl0IGF1dG9t
YXRpY2FsbHkuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj4yKSBhY2Nlc3NpYmlsaXR5IGJ5IGZp
bGUgc3RydWN0dXJlIG1heSBjYXVzZSBzb21lIHJlYWxseSBzaG9ydCBmaWxlcy4mbmJzcDs8L2Rp
dj48ZGl2Pjxicj48L2Rpdj48ZGl2PjMpIEl0J3MgaW1wb3NzaWJsZSB0byBncm91cCByZWxhdGVk
IGNsYXNzZXMgaW4gb25lIGZpbGUgYnV0IHN0aWxsIGhpZGUgaW1wbGVtZW50YXRpb24gZGV0YWls
cyBpbnNpZGUgZWFjaCBjbGFzczwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+SSB0aGluayB0aGF0
IGl0IHRoZSBiZXN0IHNvbHV0aW9uIGlzIHRvIG1ha2UgcHJpdmF0ZSBrZXl3b3JkIGRvIHdoYXQg
aXQgc3RhdGVzIC0tIGtlZXAgdGhlIGNsYXNzIGVsZW1lbnQgcHJpdmF0ZSB0byB0aGUgY2xhc3Mu
IEJ1dCBpZiBpdCdzIHJlYWxseSBpbXBvcnRhbnQgdG8gaGF2ZSBhIHNlcGFyYXRlIGtleXdvcmQg
Zm9yIGJhY2t3YXJkIGNvbXBhdGliaWxpdHksIGl0IHdvdWxkIGJlIHRoZSBuZXh0IGJlc3QgdGhp
bmcuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj4tLTwvZGl2PjxkaXY+SWx5YSBCZWxlbmtpeTwv
ZGl2PjwvZGl2Pgo8aW1nIHNyYz0iaHR0cHM6Ly9jaTUuZ29vZ2xldXNlcmNvbnRlbnQuY29tL3By
b3h5LzE2MVVwUjF1VFREWXRiQThodDVCLWdVQXA1MHl5eDVPeXdPSVczakhoelRybnNxZU1rWnBp
cGt1TTdMZnlndDluaENoOUlqNHZaSk03Nk1CWlNnZHVGMWx4Q3BFc0hlRWpZRkNpYm5LWERaMkpD
ZlphYl92Nlk4aGRGVWNaVWExbGJRX0hUOFFXdmVXeGxMRk8tcVpxYV9yWmhmX2tiR2FOd3U0MWg4
Zm9WazlkMklIVUV1UUtidk5scjE2NjhxNmRDd2phM2Q3YkJSVG00TFdlZlB0d3ZZNE41OWpNMUV3
UDd6Zjh2dmJNd01DWjhoaTl6cnc5d1JHdzh5Z0xkNlZ4Vjh1Z2F6c3hScTdzRnRWR241X0p2SVRM
MnNESUFNbWhRQXVJSFA5U3l5OS1XQXJWSDVsMlVIa3p4U3p3UUNEcHFoc01tbHdKSEVpQkRYdmZK
UDhpcHg1LU5rWUNKZ0FtYlpzV0dBWldvT2ZPelFYbVBqNG5SQnh2VUNFdWlQTmdwaXcwRmhYWUh6
azNDOGUyb25QR2xVdnBnSHVJaURMVzEtYmExQTJ5UzQ9czAtZC1lMS1mdCNodHRwczovL3UyMDAy
NDEwLmN0LnNlbmRncmlkLm5ldC93Zi9vcGVuP3Vwbj1laGtQck9xc2xzMEF2OHdxLTJCRVJ2c2tJ
dE9sLTJGc29LTTI1UEUtMkY2Sk5IeVJQNE1vMHNweHZZeXdTUVdxVWFKRWdDd2dMWk5nNkg4MWFD
SHR1TFZhTXdIRGkzWEtGZEpvSnJFOElzNVc0R2NjLTJCRThWd093Tm12V2hXRTZENy0yRmJ2OTEw
QU5Fd0g0cThBTi0yQjA5b3prc0VFN25ZZUpKd1pBVFBUTUl1bkF1bFJsdGZKaGpNQmRwVkgyMGRZ
cWZERWMwTTMwM0RjZ1JWeUs1OEh0MjQtMkI2SmIyNGhYcGtEMXZwRkRXM2NQbVhCUWdEdkktM0Qi
IGFsdD0iIiB3aWR0aD0iMSIgaGVpZ2h0PSIxIiBib3JkZXI9IjAiIHN0eWxlPSJtaW4taGVpZ2h0
OiAxcHggIWltcG9ydGFudDsgd2lkdGg6IDFweCAhaW1wb3J0YW50OyBib3JkZXItd2lkdGg6IDBw
eCAhaW1wb3J0YW50OyBtYXJnaW46IDBweCAhaW1wb3J0YW50OyBwYWRkaW5nOiAwcHggIWltcG9y
dGFudDsgZGlzcGxheTogbm9uZSAhaW1wb3J0YW50OyI+Cl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXzx3YnI+X19fX19fX19fX19fX19fX188YnI+CnN3aWZ0LWV2b2x1dGlvbiBtYWlsaW5n
IGxpc3Q8YnI+CjxhIGhyZWY9Im1haWx0bzpzd2lmdC1ldm9sdXRpb25Ac3dpZnQub3JnIiB0YXJn
ZXQ9Il9ibGFuayI+c3dpZnQtZXZvbHV0aW9uQHN3aWZ0Lm9yZzwvYT48YnI+CjxhIGhyZWY9Imh0
dHBzOi8vbGlzdHMuc3dpZnQub3JnL21haWxtYW4vbGlzdGluZm8vc3dpZnQtZXZvbHV0aW9uIiBy
ZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2xpc3RzLnN3aWZ0Lm9yZy88
d2JyPm1haWxtYW4vbGlzdGluZm8vc3dpZnQtPHdicj5ldm9sdXRpb248L2E+PGJyPgo8L2Jsb2Nr
cXVvdGU+PC9kaXY+PC9kaXY+" style="height:0;width:0;max-height:0;max-width:0;overflow:hidden;font-size:0em;padding:0;margin:0" class="">​</div></div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=nE9rxSXA5G4kxsTVkgv43pXkLx-2B36P-2BPNJufHeY0dgdP13mh3B2CeBBOx1GxBZpoov5ekcHr7aHE-2BT4Y8sZ4BEzqlxrNl-2BCT3yrbogbg0XfDILOkmrcLaAg4pp7uk6Jk4euGl4d1drwbyh4jWyR-2BZhx6FdOZFv4bborE5O1TgjT9vFJ1PQh0sKnoOmY6qLPlsgnrFKRB15kAZD-2BExvP40obANc0Sl8yEdazC44JcHok-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" 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=""></div></blockquote></div><br class=""></body></html>