[swift-evolution] final + lazy + fileprivate modifiers

[Vladimir.S]

On 20.02.2017 20:04, Joanna Carter wrote:
>
>> 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?

To provide access for internals of my type for code in current file only,
and don't for any extension/subtype in other files. I.e. 'friend' classes 
in the same file, but don't want to provide any details out of the file.

>
>> 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.

I assume the 'extensible' modifier should be limited by current module only.
I.e. in my understanding 'extensible' : "in current file and in 
subtypes/extensions in other files inside the module". I believe there is a 
consensus that Swift should not export "private" API out of the 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
>
>