[swift-evolution] [Draft] A Consistent Foundation For Access Control: Scope-Bounded Capabilities

[Matthew Johnson]

> On Mar 3, 2017, at 3:19 AM, Adrian Zubarev via swift-evolution <swift-evolution at swift.org> wrote:
> 
> (1) It seems odd to use scope as both an access control modifier alone and as a function-like attribute. Perhaps something like access(set, scope) would be better than scope(set). As it is, we’re conflating scope with meaning visibility and lexical scope—I found that very confusing.
> I like the idea of calling it access instead of scope, but I’d prefer keeping it as an access modifier instead of an attribute.
> 
I’m coming around to this view as well.  I’m going to give it a little bit more thought but will likely be updating the proposal to reflect this soon.
> (2) I think that the attribute should be spelled @access like other attributes in Swift, @availability for example. This seems more consistent.
> I must disagree here, because this proposal aims to replace all current access modifiers with a whole new model, but for simplicity keep aliases intact. That means scope(…) can be used as a standalone modifier if you’re someone who don’t want to use public, open etc. The implication of an access modifier is that it doesn’t need the @ attribute prefix.
> 
> My personal question is, what happens to static in classes? I cannot remember where I read it before, but I remember that static is an alias for final class. Does it mean that public static in classes will become an alias for scope(call, everywhere) scope(override, nowhere) class?
> 
It would be really helpful if you can find a reference to this somewhere.  If it’s possible to define static in terms of this system also that would be pretty cool.
> @Matthew: I’d really appreciate if you could add a few simple examples using scope(…) in real code to understand it’s behavior (I’m not asking for some code that makes sense, just something that explains the behavior of the access modifier). I’m kinda having hard times to follow the idea of overloading the typealiases in some corners.
> 
I'm not sure I follow what you mean by “overloading the typealiases”.  Can you elaborate?  If you can provide examples of things that you’re having trouble understanding that would be helpful.  I will be happy to include additional examples where they can add clarity.
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170303/44f30db4/attachment.html>