[swift-evolution] [discussion] SPI?
Mathew Huusko V
mhuusko5 at gmail.com
Tue Aug 15 06:03:52 CDT 2017
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/233fd7c1/attachment.html>
More information about the swift-evolution
mailing list