[swift-evolution] final + lazy + fileprivate modifiers

[David Sweeris]

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.

- Dave Sweeris