[swift-evolution] SE-0025: Scoped Access Level, next steps

[Howard Lovatt]

How about public, private, private(#file), and private(#module)? At a later
date, if needed, private(S1, S3, ...) could be added. This would be a
minimal change and not stop an extension in the future if requested.

On Thursday, 31 March 2016, James Campbell via swift-evolution <
swift-evolution at swift.org> wrote:

> What about local for a file only or scope definition ?
>
> Sent from Supmenow.com <http://supmenow.com>
>
>
>
>
> On Wed, Mar 30, 2016 at 12:39 PM -0700, "Jordan Rose via swift-evolution"
> <swift-evolution at swift.org
> <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>> wrote:
>
> Ah, sorry! Those are all clear to me; it's the possibility of writing some
>> *other* module name there that would have the wrong implications.
>>
>> Jordan
>>
>> On Mar 30, 2016, at 12:38 , Ross O'Brien <narrativium+swift at gmail.com
>> <javascript:_e(%7B%7D,'cvml','narrativium%2Bswift at gmail.com');>> wrote:
>>
>> Damn, and I thought it was clear all this time that 'private(module)', or
>> 'private(#module)', or 'moduleprivate', meant that the symbol is visible
>> only inside the module. It's always been a suggested replacement specifier
>> for 'internal'.
>>
>> On Wed, Mar 30, 2016 at 6:33 PM, Jordan Rose via swift-evolution <
>> swift-evolution at swift.org
>> <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>> wrote:
>>
>>>
>>> On Mar 29, 2016, at 17:47 , Brent Royal-Gordon <brent at architechies.com
>>> <javascript:_e(%7B%7D,'cvml','brent at architechies.com');>> wrote:
>>>
>>> If Scala style access modifiers were adopted for Swift then a
>>> private(file) modifier would also be necessary to give the current private
>>> functionality.
>>>
>>>
>>> I could imagine having these options:
>>>
>>> public // visible to all everyone
>>> private(scope-name, scope-name, …) // visible to specified scopes (plus
>>> current scope)
>>> private // visible only to current scope
>>>
>>> scope-name could perhaps be:
>>>
>>> * A type name (or Self, which would mimic C++-style private, or perhaps
>>> even C++-style protected depending on how we treat inheritance)
>>> * A module name (or #module for the current module)
>>> * A file name string (or #file for the current file)
>>>
>>> And then the default would simply be `private(#module)`.
>>>
>>> Alternatively, the parameterized level could be given a different name,
>>> like `internal` or `shared`. If that were the case, then `#module` might
>>> simply be the default.
>>>
>>>
>>> I've actually thought about this before (well, at least at the module
>>> level) and ultimately decided it was a bad idea for it to be part of the
>>> access control system. Why? Because there's nothing "private" about sharing
>>> with another module, even if it's just *one* other module.
>>>
>>> - You don't get any secrecy because you have to publish all symbols and
>>> metadata as public.
>>> - You can't optimize based on knowledge of how the declaration is used.
>>> - Exposing something to another module can be viral, just like making
>>> something 'public' would be viral: all of a type's protocol conformances
>>> are exposed, a class's superclass must be exposed, all the types in a
>>> function signature have to be exposed (or already public).
>>>
>>> All of this means that this behaves more like "public" than like
>>> "private"; it's "public, but not the *entire* public". The restriction
>>> on use sites is an artificial one.
>>>
>>> Now, it *is* a very useful feature! Apple, of course, does this all the
>>> time with its "SPI". But I think the right form of the feature is to be
>>> able to tag a bunch of public declarations as "SPI" or "limited" or
>>> "limited to group 'X'" or possibly even "limited to module 'X'", and then
>>> have a tool to *strip them out* of the swiftmodule file when you're
>>> ready to ship this module to people. That way you're enforcing your
>>> limitations as much as possible, while still using the same binaries for
>>> both internal and external clients. (Remember that the swiftmodule file
>>> serves essentially the same purpose as header files in C.)
>>>
>>>
>>> At the file level, there's nothing inherently wrong with this idea, but
>>> I don't think there's enough gain to writing file strings directly in
>>> source files. Pointing to a future "comprehensive submodules model" would
>>> be disingenuous because that's a *huge* feature with a lot of subtlety,
>>> but I think "just make this accessible to one other file" is additional
>>> complexity for not much gain. It's also subject to slippery-slope: once one
>>> file is added, I don't think anyone would think too hard about adding a
>>> *second* file, and then…
>>>
>>> Jordan
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>
>>

-- 
-- Howard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160331/e10dcd41/attachment.html>