It looks like a `hidden` access control has been discussed before: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170213/031881.html Not directly related, but would serve a similar purpose.
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 ( https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160718/024666.html), 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. 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). 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 https://github.com/apple/swift/blob/6573a5fe41b63da476278caa7ba7ee9e3c246b25/lib/AST/Decl.cpp#L396 to (remove the `isStdlibModule` check) not just check for underscores, but check for a new `@_hidden` directive? On Tue, Aug 15, 2017 at 12:03 PM, Mathew Huusko V <[email protected]> wrote: > Yes, sorry. First and foremost I'm referencing SPI access control as > mentioned in https://github.com/apple/swift/blob/master/docs/ > LibraryEvolution.rst#backdating, https://github.com/apple/ > swift/blob/master/docs/AccessControlInStdlib.rst#public, > https://github.com/apple/swift/blob/master/docs/AccessControl.rst#access- > control, etc. > and "used" in places like https://github.com/apple/ > swift/blob/master/stdlib/public/core/String.swift#L864 > > 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. > > In my mind there would be two cases to cover: > 1) Restricting SPI to a known client. `public(client: Foundation)` on a > type or member would only make it accessible to Foundation. > 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. > > On Tue, Aug 15, 2017 at 5:24 AM, Félix Cloutier <[email protected]> > wrote: > >> Could you clarify? What do you hope to achieve beyond access/visibility >> control? >> >> > Le 14 août 2017 à 07:19, Mathew Huusko V via swift-evolution < >> [email protected]> a écrit : >> > >> > 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. >> > _______________________________________________ >> > swift-evolution mailing list >> > [email protected] >> > https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
