[swift-evolution] access control proposal

Ilya ilya at harmonicsense.com
Mon Dec 7 10:54:12 CST 2015

Classified is a nice name for this.

I think that it would not be accessible from extensions (otherwise it would
be easy to break into the internals that the class wants to make

Ilya Belenkiy

On Mon, Dec 7, 2015 at 9:25 AM plx <plxgithub at gmail.com> wrote:

> If such an extra-private access-control level (`classified`?) existed, how
> would it be intended to behave in snippets like below?
>     private class Example {
>       classified var data: TopSecretData
>     }
>     extension Example: Equatable {
>     }
>     func ==(lhs: Example, rhs: Example) -> Bool {
>       return lhs.data == rhs.data
>       // ^ ??? possible or not?
>     }
> …(assuming the rest of the language largely behaves as-before).
> When such `classified` properties behave like values you could perhaps
> declare them as `private classified(set) var` but that wouldn’t really add
> much safety when they behave like references.
> On Dec 7, 2015, at 7:45 AM, Ilya via swift-evolution <
> swift-evolution at swift.org> wrote:
> Also, one problem with the current approach is that it's all or nothing.
> The classes in one file see everything from the other classes, and it may
> be useful to limit that and share only some additional APIs with those
> related classes, but not all of the implementation details / internal
> state, while still hiding those same APIs from unrelated classes.
> Currently, there is no way of doing it, even when splitting code into
> separate files (the class state must be all in one place and can't be in an
> extension).
> --
> Ilya Belenkiy
> On Mon, Dec 7, 2015 at 8:17 AM Ilya <ilya at harmonicsense.com> wrote:
>> My main proposal was not to change the semantics of private (although I
>> would like that) but to introduce a way to keep class implementation
>> details inaccessible to anything outside the class. I think that it should
>> still be possible and useful to have the current level of sharing (I would
>> just name it differently, given what private usually means in other
>> languages).
>> Just as it is convenient to group several related classes that can refer
>> to each other's implementation details, it is very convenient to have
>> several classes that don't do this but are still related in other important
>> way, for example related APIs or classes that are based on the same
>> implementation idea (like array based data structures).
>> Having all code in one place rather than jumping through many small files
>> is a very nice thing to have because it really helps to keep everything
>> consistent. The more manual work people have to do for consistency, the
>> more likelihood that it won't be done.
>> --
>> Ilya Belenkiy
>> On Mon, Dec 7, 2015 at 12:21 AM John McCall <rjmccall at apple.com> wrote:
>>> > On Dec 5, 2015, at 8:39 PM, Ilya via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>> >
>>> > I think the it would help a great deal to have an access level
>>> modifier that is really private and visible only inside the class itself.
>>> Right now, the only way to hide implementation details for a class is to
>>> hide the class code in a separate file, which is very inconvenient for
>>> several reasons:
>>> >
>>> > 1) the meaning of the code changes depending on which file the class
>>> is in. It's very easy to accidentally expose class internal details and
>>> then call class elements that are meant to be used only inside the class.
>>> Having a keyword for class internals will allow the compiler to ensure that
>>> only the public API for the class is used from the outside world. The user
>>> can check types on his own, but it's better that the compiler does it
>>> automatically. Similarly, the user can check that only the proper APIs are
>>> called, but it's better that the compiler does it automatically.
>>> >
>>> > 2) accessibility by file structure may cause some really short files.
>>> >
>>> > 3) It's impossible to group related classes in one file but still hide
>>> implementation details inside each class
>>> >
>>> > I think that it the best solution is to make private keyword do what
>>> it states -- keep the class element private to the class. But if it's
>>> really important to have a separate keyword for backward compatibility, it
>>> would be the next best thing.
>>> But on the flip side, with your proposed semantics for private, it would
>>> be impossible to write a group of related types, functions, and extensions
>>> that do need to refer to each other’s internal details without exposing
>>> those details to the entire module.  That’s not really acceptable.
>>> The Swift language rule encourages you to put independent definitions in
>>> different files.  That definitely means that, if you want to enforce very
>>> tight separation of concerns, you’ll end up with more and smaller files.
>>> You haven’t explained why that’s really a *problem*, though.
>>> John.
>>  _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151207/9206d855/attachment-0001.html>

More information about the swift-evolution mailing list