[swift-evolution] [swift-evolution-announce] [Review] SE-0025 Scoped Access Level

[Ilya Belenkiy]

> Wrap it how? You can't introduce arbitrary scopes inside file scope; that
is, this is already illegal*:

> Introducing a scope would require you to declare or extend a type. Thus,
moving something into a containing scope in order to allow you to "see"
into it would also, by necessity, move the type itself, forcing you to
change any code that uses the type.


Yes, that's what I meant: making a class nested.


>  It would be far easier for someone trying to get access to internal
details to simply change `scoped` to `private`.


That may be, but it's still important to preserve the semantic meaning of
"scoped" -- it should make anything marked with "scoped" be completely
hidden from outside of the scope. It's a guarantee that nothing outside the
scope can break what the scope aims to hide. As long as the code inside the
scope hasn't changed, any code changes outside of it will not break it.
It's the same kind of guarantee that we get with "private" (as long as the
file hasn't changed, changes in other files  will not break the code inside
the file).


> When considering the `scoped` proposal, you must remember that `scoped`'s
protections are paper-thin. You are already in the very file which declares
the member `scoped`; if you want to deliberately violate that protection,
all you must do is change that to `private`.


Exactly the same argument is true about "private". If you want to
deliberately violate protection by "private", all you must do is change
that to "internal". As long as you haver access to source code, you can
break anything like that. The "paper-thin protection" argument applies to
anything in the source code. For example, you could change any variable's
type from T to T! and bypass any compiler's checks for optionals. The whole
point of having types and access control is that you know what operations
are allowed and that as long as *something else* changes, the compiler
still protects your type. The protection comes in the form of a compilation
error saying that something is not allowed, given the contract that you
specified. If you have access to source code, you can change the contract,
but in this case the compilation error is the most you can hope for, and
it's not "paper-thin".



On Fri, Mar 4, 2016 at 10:14 PM Brent Royal-Gordon <brent at architechies.com>
wrote:

> > A very important property of the proposal is that anything declared
> "scoped" is completely sealed inside its scope and cannot be accessed from
> the outside. This means that the scope can be moved anywhere in the file
> without the danger of introducing access to implementation details.
> >
> > Allowing a containing scope to see "scoped" in its inner scope would
> mean that someone could just wrap a scope in another scope to gain access
> to implementation details without changing anything in the scope itself.
> The whole point of the proposal is to protect against something like this
> and make sure that implementation details remain hidden from anything
> outside the scope.
>
> Wrap it how? You can't introduce arbitrary scopes inside file scope; that
> is, this is already illegal*:
>
>         do {
>                 extension SomeType {
>                         scoped func secret() { ... }
>                 }
>
>                 func intruder(some: SomeType) {
>                         some.secret()
>                 }
>         }
>
> Introducing a scope would require you to declare or extend a type. Thus,
> moving something into a containing scope in order to allow you to "see"
> into it would also, by necessity, move the type itself, forcing you to
> change any code that uses the type. It would be far easier for someone
> trying to get access to internal details to simply change `scoped` to
> `private`.
>
> When considering the `scoped` proposal, you must remember that `scoped`'s
> protections are paper-thin. You are already in the very file which declares
> the member `scoped`; if you want to deliberately violate that protection,
> all you must do is change that to `private`.
>
> To the extent there is value in `scoped`, it is because it prevents
> *mistakes*, not *malice*. So when we're thinking about what `scoped` should
> do, we should ask, "What is likely to be a mistake?"
>
> I submit that, if you nest one declaration inside another, and the outer
> declaration accesses implementation details of the inner declaration, that
> is not likely to be a mistake. If it would be, you can always put the inner
> declaration into its own extension; then any code which accesses its
> implementation details will have to be deliberately put in that particular
> extension.
>
> This does not permanently wall off those implementation details from
> anything outside the type, but there is *nothing* we can do that will do
> that, because you are already in the file and can always change the the
> `scoped` to `private`.
>
>
>
> * The REPL won't show this behavior because it allows arbitrary statements
> at the top scope; you'll have to try it in a .swift file.
>
> --
> Brent Royal-Gordon
> Architechies
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160305/63e736af/attachment.html>