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

[David Waite]

I wonder if perhaps it would be clearer if public was used for indicating something was published, even if it is published to a restricted set:

public(#all)		- expose outside the framework, shortened to public
public(#module)	- exposed module-wide, default if omitted
public(#file)		- expose to other code within the file
private			- not exposed outside lexical scope

named contexts such as a particular type or other module would be possible in the future via non-# names, and multiple contexts could be possible in the future via comma-separated values

-DW

> On Mar 30, 2016, at 7:24 PM, Matthew Judge via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Some other module name would seem to suggest "public(scope-name)"
> 
> I agree "private(scope-name)" should only be used to disambiguate between the concentric scope circles (if I declare something in the main class it is visible in the main class declaration scope, the file scope, and the module scope... And I can declare something private to any of those scopes).
> 
> On Mar 30, 2016, at 15:39, Jordan Rose via swift-evolution <swift-evolution at swift.org <mailto: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 <mailto:narrativium+swift 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 <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>>> On Mar 29, 2016, at 17:47 , Brent Royal-Gordon <brent at architechies.com <mailto: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 <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> 
>>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> 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/20160330/17337e56/attachment.html>