On 07.10.2016 11:24, Haravikk via swift-evolution wrote:
On 7 Oct 2016, at 07:39, David Hart via swift-evolution
<[email protected] <mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
