[swift-evolution] final + lazy + fileprivate modifiers

[Goffredo Marocchi]

I think this is the not an easy topic to get right, there is not enough evidence in practice to remove it in terms of it being actively harmful and having a better solution at hand. What you see as being not awesome for protocols and extensions others may see taking it away as a sacrifice that does not make POP better in and of itself (seriously now, this is what will trip people up when learning Swift and not default methods and static vs dynamic dispatching or implementing copy on write for custom value types using reference types inside for backing storage?) and does not help people write classes better...

Sent from my iPhone

> On 19 Feb 2017, at 17:14, David Hart <david at hartbit.com> wrote:
> 
> 
>> On 19 Feb 2017, at 18:10, Goffredo Marocchi <panajev at gmail.com> wrote:
>> 
>> Good thing that both can exist then :). One day we may even get things such as abstract classes and be allowed to model abstentions wth classes and reference types better without it being seen as an attack to value types ;)..
> 
> But if both exist, we are keeping two access levels that are quite similar to please two groups of people: people that are used to scoped-access from other languages and people who prefer an access level which works better with Swift’s idioms. It’s wasteful to keep two around IMHO.
> 
>> Sent from my iPhone
>> 
>>> On 19 Feb 2017, at 13:55, David Hart <david at hartbit.com> wrote:
>>> 
>>> 
>>> 
>>>> On 19 Feb 2017, at 10:20, Goffredo Marocchi via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>> The current private is closer to other languages than the previous one we had which now has in fileprivate a better name.
>>> 
>>> It is closer, but it's not a goal for Swift to always follow conventions of other languages. It's useful sometimes. But in this case it goes directly against the philosophy of Swift's extension feature. Swift should be allowed to go against the norm when it serves the languages. And in this case, if only one private should exist, it's the file-s open one.
>