[swift-evolution] final + lazy + fileprivate modifiers

[Vladimir.S]

On 17.02.2017 20:16, David Sweeris via swift-evolution wrote:
>
>
>
> Sent from my iPhone
>> On Feb 17, 2017, at 01:02, Rien <Rien at Balancingrock.nl> wrote:
>>
>>
>>> On 17 Feb 2017, at 03:36, David Sweeris via swift-evolution
>>> <swift-evolution at swift.org> wrote:
>>>
>>>
>>>> On Feb 16, 2017, at 14:34, Slava Pestov via swift-evolution
>>>> <swift-evolution at swift.org> wrote:
>>>>
>>>> While we’re bikeshedding, I’m going to add my two cents. Hold on
>>>> to your hat because this might be controversial here.
>>>>
>>>> I think both ‘private’ and ‘fileprivate’ are unnecessary
>>>> complications that only serve to clutter the language.
>>>>
>>>> It would make a lot more sense to just have internal and public
>>>> only. No private, no fileprivate, no lineprivate, no protected.
>>>> It’s all silly.
>>>
>>> Eh, I've used `private` to keep myself honest in terms of going
>>> through some book-keeping functions instead of directly accessing a
>>> property.
>>
>> But is that not an argument to get rid of ‘private’ & ‘fileprivate’?
>>
>> With great power there comes great responsibility ;-)
>
> I don't see how... I used `private` on some dicts that interact with
> each other (faking a lightweight database) to ensure I was using my
> type's subscript functions (which handle updating all the dicts
> correctly) instead of directly accessing the dictionaries in some areas
> where the interactions theoretically wouldn't matter. Since I was able
> to mark those properties as private, I know that all the access to those
> properties goes through the proper book-keeping functions. Not only does
> this reduce the opportunity for bugs, it makes it far simpler to change
> the implementation later if I decide it should be backed by a "proper"
> database since everything that directly touches the storage will be
> right there in the type definition instead of spread through however
> many extensions across however many files.
>

David, I assume personally you see a benefits of 'private' as it is 
currently and don't support extending its scope to "type and subtypes and 
extensions in the same module"? My suggestion was to extend it...

Personally I'd like to have a way to say all of this as access scope(in 
addition to current public/internal/fileprivate):
1. type only
2. type and subtypes in the same module
3. type and subtypes and extensions in the same module
4. file and subtypes in the same module
5. file and subtypes and extensions in the same module

Probably we could have just (3) without (2), and (5) without (4), need to 
discuss if it is important to be able to provide access to subtype but not 
for extensions.

So, it seems for me like we need to return 'public' keyword where it was in 
Swift2(so to have public/internal/private "file"-based scope), and 
introduce well-designed scope access levels with own keywords.

For example, if we really need just (3) and just (5) (without 2 and 4):
typeprivate - type only
typeprotected - type and subtypes and extensions in the same module
typeinternal - file and subtypes and extensions in the same module

Opinions?

> - Dave Sweeris _______________________________________________
> swift-evolution mailing list swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>