<div dir="ltr"><span><p style="margin:0px;line-height:normal;font-family:'Helvetica Neue'"><span style="font-kerning: none">> Wrap it how? You can't introduce arbitrary scopes inside file scope; that is, this is already illegal*:</span></p>
<p style="margin:0px;line-height:normal;font-family:'Helvetica Neue';min-height:15px"><span style="font-kerning: none"></span>> 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.</p><p style="margin:0px;line-height:normal;font-family:'Helvetica Neue';min-height:15px"><br></p><p style="margin:0px;line-height:normal;font-family:'Helvetica Neue';min-height:15px">Yes, that's what I meant: making a class nested. </p><p style="margin:0px;line-height:normal;font-family:'Helvetica Neue';min-height:15px"><br></p><p style="margin:0px;line-height:normal;font-family:'Helvetica Neue';min-height:15px"><span style="font-family:'Helvetica Neue'">> It would be far easier for someone trying to get access to internal details to simply change `scoped` to `private`.</span><br></p><p style="margin:0px;line-height:normal;font-family:'Helvetica Neue';min-height:15px"><br></p><p style="margin:0px;line-height:normal;font-family:'Helvetica Neue';min-height:15px">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).</p><p style="margin:0px;line-height:normal;font-family:'Helvetica Neue';min-height:15px"><br></p><p style="margin:0px;line-height:normal;font-family:'Helvetica Neue';min-height:15px"><span></span></p><p style="margin:0px;line-height:normal;font-family:'Helvetica Neue'"><span style="font-kerning: none">> 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`.</span></p><p style="margin:0px;line-height:normal;font-family:'Helvetica Neue'"><span style="font-kerning: none"><br></span></p><p style="margin:0px;line-height:normal;font-family:'Helvetica Neue'"><span style="font-kerning: none">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".</span></p><p style="margin:0px;line-height:normal;font-family:'Helvetica Neue'"><span style="font-kerning: none"><span></span></span></p><div><br></div></span><p></p><p></p></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Mar 4, 2016 at 10:14 PM Brent Royal-Gordon <<a href="mailto:brent@architechies.com">brent@architechies.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> 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.<br>
><br>
> 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.<br>
<br>
Wrap it how? You can't introduce arbitrary scopes inside file scope; that is, this is already illegal*:<br>
<br>
do {<br>
extension SomeType {<br>
scoped func secret() { ... }<br>
}<br>
<br>
func intruder(some: SomeType) {<br>
some.secret()<br>
}<br>
}<br>
<br>
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`.<br>
<br>
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`.<br>
<br>
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?"<br>
<br>
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.<br>
<br>
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`.<br>
<br>
<br>
<br>
* 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.<br>
<br>
--<br>
Brent Royal-Gordon<br>
Architechies<br>
<br>
</blockquote></div>