[swift-evolution] private & fileprivate

[Vladimir.S]

On 07.10.2016 11:24, Haravikk via swift-evolution wrote:
>
>> On 7 Oct 2016, at 07:39, David Hart via swift-evolution
>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>
>> Hello community,
>>
>> From all the proposals which has gone into Swift 3, *[SE-0025] Scoped
>> Access Level* is the only one I’m having second thoughts about. Before
>> launching a discussion around it, I’m curious to know if it's worth
>> discussing it or if the “ship has sailed”. As the plan is to allow future
>> versions of Swift to break source-compatibility in certain rare
>> scenarios, perhaps we have a chance to reconsider certain proposals?
>>
>> Regards,
>> David.
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> What in particular don't you like about it?
>
> Personally I still don't like the use of fileprivate as the keyword, I was
> very much in favour of a bracketed system like:

FWIW, I fully agree with you and I do believe your suggestion just much 
better than current status quo. It is much clearer what private(module) 
means than 'internal' and private(scope) than just 'private', private(file) 
is 1000% better than fileprivate ;-). Currently IMO names are not 
consistent : if we have 'fileprivate', then we need 'scopeprivate' and 
'moduleprivate'.. but these are just ugly(just like fileprivate ;-) )
IMO

>
> private(scope)Current private (I think, it doesn't appear to be equivalent
> to protected in other languages anyway so I wouldn't call it type).
> private(file)Current fileprivate
> private(module)Current internal/default when omitted
> publicCurrent public
>
> I favour this because it groups all restrictive access levels under private
> (since they're all some form of private) with an optional modifier that's
> explicit about what it's for. Also, it would have scope to move things like
> final into a modifier too, so you might declare a method as public(final),
> or public(open) if that's implemented later and so-on. Just seems like a
> generally more flexible setup that also reduces the number of keywords
> required.
>
> Some may feel it's noisy, but personally I don't see it as a problem as it
> always comes before the func/var/let keyword, generics and function name,
> so it's not like it's near anything where the (minor) noise reduces
> readability.
>
> But yeah, having used the new fileprivate for a little while I just don't
> like it; it may partly come down to the fact that I use fileprivate a lot
> more than I use regular private. If we were to adopt the above scheme I
> would recommend that private(file) be the default for use of the plain
> private keyword, unless we gain the ability to specify private(type) (i.e-
> protected in most other languages), as private(scope) seems like it's the
> less common, at least in my experience.
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>