> On Mar 29, 2016, at 10:18 AM, Jordan Rose <[email protected]> wrote:
>
> A good handful of people already enumerated several cases where file-based
> scoping is useful, and I very much agree. Leaking helper operations across an
> entire module just because they can't be lexically scoped, or don't make
> sense to, doesn't seem like a good answer to me.
I know, I'm one of them.
However, this thread is fairly disconcerting about how granular many of the
suggestions are heading towards. We can try to solve for all of the cases or we
can provide mechanism that works well for the majority of cases. I'm actually
in the camp of keeping the levels as they are. There is always going to be some
level of leakage unless you provide a mechanism to provide very explicit access
control modifiers.
The question at the heart of this proposal is how "correct" is Swift really
going to be in defining access control modifiers?
One can argue that file-based access control is required, for many use cases,
because it's not possible to limit usage to be "more correct". If I want to
expose the private details of my type to an extension, how do I do that? Today,
file-based, but tomorrow, is there a `protected` for this? What about only to
all extensions within the module? Is that `protected internal`? Is there a way
to limit the extensions that can have access to the privates, because there are
real scenarios for that as well?
Then we need to go down the rabbit-hole for type-based access control modifiers
as well, though maybe that's already alluded to with the extensions example, so
we get `protected` and `protected internal` there as well.
So this gives us public, internal, private, file-based, protected
(protocol/extension based), protected (inheritance based), protected internal
(protocol/extension based), and protected internal (inheritance based).
And let's not forget the desire to share privates with others that are not in
our access control scope, so we're back to needing something like `friend` to
essentially merge other types into the same access control scope.
I really feel like I'm watching the evolution of C++ access modifiers in Swift.
If that's the route the language and community wants to go, then ok. However,
if Swift is really going to re-look at access levels, just looking at scoped
access levels does not seem sufficient; it solves one, very narrow case, while
ignoring many of the other cases.
-David
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
