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
