[swift-evolution] final + lazy + fileprivate modifiers

[David Sweeris]

> On Feb 17, 2017, at 11:25 AM, Vladimir.S <svabox at gmail.com> wrote:
> 
> 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…

I wouldn’t mind something synonymous with C++’s “friend”, although I don’t really have an opinion on the spelling. Right now, I use “fileprivate” to kinda fake it by putting everything that needs access to property/function in question in the same file. That approach doesn’t really scale well (or at all, if you want to publish a class that you intend your clients to subclass), but so far the codebase I’m using it in is small enough that’s just an annoyance rather than an actual issue.

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

Personally, I’d prefer “access(option)” over “optionaccess”, but I’m more interested in getting agreement on the functionality than how it’s spelled. My only strong feeling on the matter of spelling is that it should be clear and consistent… “davesCrutch”, while arguably accurate, would be a horrible name because its meaning is so unclear, and even though it’d be my preferred spelling, I would be opposed to adding “private(type)” unless we also replace “fileprivate” with “private(file)”.

- Dave Sweeris