[swift-evolution] [discussion] SPI?

[Mathew Huusko V]

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 <mhuusko5 at 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, 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 at 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 at 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 at swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170815/57dc2905/attachment.html>