<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">https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst#backdating</a>, <a href="https://github.com/apple/swift/blob/master/docs/AccessControlInStdlib.rst#public">https://github.com/apple/swift/blob/master/docs/AccessControlInStdlib.rst#public</a>, <a href="https://github.com/apple/swift/blob/master/docs/AccessControl.rst#access-control">https://github.com/apple/swift/blob/master/docs/AccessControl.rst#access-control</a>, etc.<div>and "used" in places like <a href="https://github.com/apple/swift/blob/master/stdlib/public/core/String.swift#L864">https://github.com/apple/swift/blob/master/stdlib/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 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="gmail-"><br>
> Le 14 août 2017 à 07:19, Mathew Huusko V via swift-evolution <<a href="mailto:swift-evolution@swift.org">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">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br>
</blockquote></div><br></div></div></div>