<div dir="ltr">It looks like a `hidden` access control has been discussed before: <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170213/031881.html">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170213/031881.html</a><div>Not directly related, but would serve a similar purpose.</div><div><br></div><div>I'm fairly sure whether it's revisiting protected, or something like 'hidden' with special imports, or getting to SPI access control, or just getting to better modules/imports (<a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160718/024666.html">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160718/024666.html</a>), it's not going to happen soon, requiring a ton of debate and design that people aren't even necessarily interested in anymore/at the moment.</div><div><br></div><div>But regardless, whatever solution(s) are implemented in whatever version of Swift, the least common denominator implication will be that internal symbols will be able to be named independently from visibility concerns (currently I use `_privateButInternalSymbol` and `_int_internalButPublicSymbol` for clarity out/inside of module, which sucks).</div><div><br></div><div>What if in the meantime, as a measure to allow stdlib and other frameworks to lock in the symbols/SPI they *would* use with full access/visibility control, we change <a href="https://github.com/apple/swift/blob/6573a5fe41b63da476278caa7ba7ee9e3c246b25/lib/AST/Decl.cpp#L396">https://github.com/apple/swift/blob/6573a5fe41b63da476278caa7ba7ee9e3c246b25/lib/AST/Decl.cpp#L396</a> to (remove the `isStdlibModule` check) not just check for underscores, but check for a new `@_hidden` directive?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 15, 2017 at 12:03 PM, Mathew Huusko V <span dir="ltr"><<a href="mailto:mhuusko5@gmail.com" target="_blank">mhuusko5@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Yes, sorry. First and foremost I'm referencing SPI access control as mentioned in <a href="https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst#backdating" target="_blank">https://github.com/apple/<wbr>swift/blob/master/docs/<wbr>LibraryEvolution.rst#<wbr>backdating</a>, <a href="https://github.com/apple/swift/blob/master/docs/AccessControlInStdlib.rst#public" target="_blank">https://github.com/apple/<wbr>swift/blob/master/docs/<wbr>AccessControlInStdlib.rst#<wbr>public</a>, <a href="https://github.com/apple/swift/blob/master/docs/AccessControl.rst#access-control" target="_blank">https://github.com/<wbr>apple/swift/blob/master/docs/<wbr>AccessControl.rst#access-<wbr>control</a>, etc.<div>and "used" in places like <a href="https://github.com/apple/swift/blob/master/stdlib/public/core/String.swift#L864" target="_blank">https://github.com/apple/<wbr>swift/blob/master/stdlib/<wbr>public/core/String.swift#L864</a><br><div><br></div><div>i.e. some way to say "this symbol is public/visible, but only for relevant clients, like associated or extension frameworks". The value add for stdlib is high, as it would be able to lock down a plethora of those public-but-underscored symbols. Personally I don't need strong access control as much as just lightly enforced visibility control (Obj-C never had real access control, everything was accessible dynamically with enough effort, but fine grained visibility via headers was extremely valuable/important to API design), but I imagine if this is going to be tackled at all, bringing it all the way is appropriate.</div><div><br></div><div>In my mind there would be two cases to cover:</div><div>1) Restricting SPI to a known client. `public(client: Foundation)` on a type or member would only make it accessible to Foundation.</div><div>2) Restricting SPI to clients interested in that SPI space. `public(SPI: StringImpl)` on a type/member would only make it visible to clients/files that explicitly `import SomeModule(SPI: StringImpl)` vs. apps casually importing SomeModule or clients interested in ArrayImpl SPI.</div><div><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 15, 2017 at 5:24 AM, Félix Cloutier <span dir="ltr"><<a href="mailto:felixcloutier@icloud.com" target="_blank">felixcloutier@icloud.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Could you clarify? What do you hope to achieve beyond access/visibility control?<br>
<span class="m_5307555329832230873gmail-"><br>
> Le 14 août 2017 à 07:19, Mathew Huusko V via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> a écrit :<br>
><br>
> Curious if SPI access/visibility control has been discussed/planned? I know the standard access control debate is long past, but this still seams rather important, especially for stdlib (and would presumably have ABI implications) and other large frameworks.<br>
</span>> ______________________________<wbr>_________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
<br>
</blockquote></div><br></div></div></div></div></div>
</blockquote></div><br></div>