[discussion] SPI?

Mathew_Huusko_V · August 14, 2017, 2:19pm

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.

fclout · August 15, 2017, 4:24am

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 <swift-evolution@swift.org> 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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Mathew_Huusko_V · August 15, 2017, 11:03am

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 <felixcloutier@icloud.com> 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 < > swift-evolution@swift.org> 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
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

Mathew_Huusko_V · August 15, 2017, 3:03pm

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

github.com

apple/swift/blob/6573a5fe41b63da476278caa7ba7ee9e3c246b25/lib/AST/Decl.cpp#L396


      
            // If this is an accessor, check if the transparent attribute was set
            // on the value decl.
            if (const auto *FD = dyn_cast<FuncDecl>(this)) {
              if (auto *ASD = FD->getAccessorStorageDecl())
                return ASD->isTransparent();
            }
          
            return false;
          }
          
          bool Decl::isPrivateStdlibDecl(bool whitelistProtocols) const {
            const Decl *D = this;
            if (auto ExtD = dyn_cast<ExtensionDecl>(D))
              return ExtD->getExtendedType().isPrivateStdlibType(whitelistProtocols);
          
            DeclContext *DC = D->getDeclContext()->getModuleScopeContext();
            if (DC->getParentModule()->isBuiltinModule() ||
                DC->getParentModule()->isSwiftShimsModule())
              return true;
            if (!DC->getParentModule()->isSystemModule())
              return false;

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 <mhuusko5@gmail.com> 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, Apple · GitHub
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 Apple · GitHub
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 <felixcloutier@icloud.com> > 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 < >> swift-evolution@swift.org> 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
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution