[swift-evolution] access control

[Dave Abrahams]

on Sat Jan 23 2016, Ilya Belenkiy <swift-evolution at swift.org> wrote:

>>> Yes, but with an API based access control, 
>> 
>> I don't know what that term means, sorry.
>
> I had to come up with this term to distinguish it from a file based
> access control. In API based access control, visibility of anything is
> tied to the declaration instead of the file it is in. 
>
> It’s the model that C++ and C# ( and I am sure many others) use. In
> file based access control, visibility of anything is tied to the file
> it is in and has little to do with the class API itself. It’s the
> model that Swift currently follows.

I disagree with your analysis.  Every declaration in Swift has a
visibility.  That visibility is attached to the declaration itself, not
to the file.  Every declaration can live in only one spot, and that's
where the visibility is set.  You can't go to another file and do
something there to alter the declaration's visibility.  The fact that we
made the most restrictive visibilty level "visibile within the file"
rather than "visible within the type" does not mean the model is
fundamentally different.

>>> anyone modifying / extending the class can instantly see the author’s
>>> intent from the API declaration, 
>> 
>> I don't see how that's different from what we have in Swift.  Private
>> APIs are the ones you don't want anyone to touch because they can break
>> your invariants.
>
> In Swift, any additional code in the same source file can use the APIs
> declared private and break your invariants. The semantic meaning of
> private is not “use only inside the class” but “use only inside this
> file”. It is currently impossible to express “use only inside the
> class” semantics.

That is true.  The question is, would having a way to express that be
worth the complexity it introduces?  Reasonable people can disagree
about that.  

>> Seeing the keyword “private” isn't enough for you in Swift, but it is in
>> C++?  Why?
>
> Because in Swift, private means “use only inside this file” and not
> “use only inside this class / scope”. In C++ private means “use only
> inside this class”. Moreover, C++ puts a special emphasis on this —
> variables are private inside the class unless the code specifically
> says otherwise.

I ended up generally being explicit about scoping in C++ anyway: The
most-accessible (public) part of a C++ class declaration should appear
at the top, so you end up with everything thereafter being public unless
you go out of your way to explicitly specify access.

>>  Defining one type per file is usually a good practice anyway.
>
> This really depends on the context. There is value in keeping similar
> concepts / implementations in the same file. 

Usually when they have an intimate relationship and need access to one
another's implementation details.  We didn't want to end up with
"friend" as in C++, so we made file-level access control what you get
from "private."

For what it's worth, my background, up until a few years ago, is as a
C++ programmer.  I was a little uncomfortable at first with the idea of
giving up a "limit-to-the-type" level of access control, but when I
considered how real C++ code was developed I realized that people
generally control changes to code at file-level granularity.  If they
want protection from themselves, they can choose the file boundaries
accordingly.  IMO it's a good trade to avoid having a wart like "friend"
in the language.  Another level of access control might be useful, but
I don't think it's crucial.

> If one class and one extension per file become a requirement,
> then private will have the same semantics as in C++. It will also
> become very inconvenient to write code because even a small extension
> with 1 method that can fit on one line will require a separate file.

Whoa, I never said anything about one extension per file, or about
requirements.

>> Without prohibiting class extensions from being made in the same file
>> where the class is defined—a capability we want to keep available to
>> class authors—that will always be the case.
>
> It doesn’t have to be. My proposal (still a pull request) provides a
> way to explicitly declare a function or a property to be private to
> the scope where it is defined. So extensions and subclasses declared
> in the same file cannot access it and break the invariant. If it’s
> applied to both class definitions and extensions, it’s very consistent
> and provides an explicit declaration of intent that can (and should)
> be enforced by the compiler.
>
>> Therefore, you have the
>> same scenario as in C++: anyone who modifies the file where a class is
>> defined might be violating its invariants.  It's just that in C++ the
>> violator has to write code between a particular set of braces.  When
>> reviewing diffs it's very common not to have enough context to see those
>> braces anyway.
>
> This is a crucial distinction. That particular set of braces defines a
> scope which acts as a black box and hides the implementation
> details. Anything outside the scope cannot damage the internal state,
> and the compiler *enforces* it. 

We do that in Swift as well; we just chose a different box boundary.

> In Swift, the compiler only enforces that the API is not visible from
> another file because the language has no way to express “this should
> be visible only in the scope to hide implementation details”. The only
> exception to that are functions inside other functions and local
> variables — right now this is the only way to completely hide
> implementation details, but it’s very limited.
>
> My main 2 points are that it’s impossible to express the intent of a
> truly local access level to hide implementation details, and because
> of that, the compiler cannot enforce this intent.
>
>> When reviewing diffs it's very common not to have enough context to
>> see those braces anyway.
>
> This depends on how thoroughly the code is reviewed. But the main
> point there is that when you find out, you know that whoever worked
> around a private API did so knowing that he was introducing a
> hack. Because Swift has no way of expressing “this is private to the
> class, not just file it’s in”, someone may not know and make a
> mistake, and the compiler cannot catch it. My proposal makes the
> intent expressible in the language and enforceable by the compiler.

I think you'll agree that if you ignore (or are ignorant of) the intent
behind the application of any given access control construct, and you
have the ability to change all the code in the project, you are likely
to break someone's invariants.  If you aren't willing to treat something
that's labelled as "private" as "don't touch unless you know what you're
doing," there's nothing the compiler can do to enforce correctness, and
there's not much difference between making make changes in the file
where it's declared and making changes between the braces where it's
declared.

>> Not at all in the same way.  In C++, you can't add methods to a class
>> outside the file where it's declared unless there's some really horrible
>> preprocessor stuff going on, and even then the class author would have
>> had to explicitly left that door open for you.
>
> True, but my proposal deals with extensions the same way it does with
> class definitions — it provides a way to hide implementation details
> in a scope (whether it be a class definition or an extension scope)
> and make them invisible to everything else including extensions or
> other extensions or anything else in the same file. It provides a way
> to express the intent in the language and enforce it by the compiler.

I think it's possible to believe that your feature would be useful
without also believing there's something fundamentally wrong with the
current model, and your arguments make it sound to me like you think
you're getting a lot more certainty from C++'s "private" than you
actually are.


-- 
-Dave