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

[Adrian Zubarev]

(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.

(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?

@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.



-- 
Adrian Zubarev
Sent with Airmail

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