[swift-evolution] final + lazy + fileprivate modifiers

Joanna Carter joanna at carterconsulting.org.uk
Mon Feb 20 11:04:33 CST 2017


> Le 20 févr. 2017 à 17:25, Vladimir.S <svabox at gmail.com> a écrit :
> 
> Well, in general I support your opinion, but there is one question not answered by your 'extensible' modifier.
> It is common to have access to type's internals in the same file from inside just other types("friend" types), not extending types.
> So, in this case we want something like fileprivate+extensible if we want also share details for extending types in other files.
> And so, IMO, 'extensible' should means 'accessible as for private but also in extending types AND INSIDE CURRENT FILE", or we need one more access modifier.

I think that was what I was intending. If 'extensible' was type-based, then, surely, whether the 'friend' was in the same file/module or whatever, the accessibility would be the same?

> Also, there is a common(IMO) opinion in the list that we should rename fileprivate to private as in Swift2.

I'm not sure why ; with 'extensible' available to code within the same file, why would you still need fileprivate anywy?

> So, I believe this will be optimal minimum of access modifiers set:
> 
> public: outside of module
> internal: anywhere inside module
> private: anywhere in current file
> scoped(hidden,*or other keyword*): as current 'private', only inside declared type
> extensible : in current file and in subtypes/extensions in other files

Otherwise known in my language as :

public - anywhere
internal - anywhere inside the module
private - only inside current type
extensible - in current file and in subtypes/extensions in other files

The only other option that might be useful is something like 'internal extensible' to limit visibility for extensible members to the current module.

Sorry, I would still like to see a waterproof argument for what is presently called fileprivate ; with the above scopes, I simply can't see the need. Unless you can convince me, that is ;-)
--
Joanna Carter
Carter Consulting



More information about the swift-evolution mailing list