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

[Adrian Zubarev]

IIRC we might want to introduce enum subtypes in the future right? In previous discussions an enum, that can be subtyped outside your own module was written as open enum. I also remember that Brent said enum sub typing should remove cases from your parent enum. So what exactly might happen with closed enum after this proposal? Will it become open closed enum? That seems really odd.

In your proposal you’re saying that the model can be enhanced on that part. How exactly would you imagine this to look like? Bikeshedding is enough for me. open(exhaustiveSwitch), then why would be need closed at all if we could write public(exhaustiveSwitch) to be consistent on that?

I’m simply trying to understand the direction it goes. Thank you for clarification on that. ;)



-- 
Adrian Zubarev
Sent with Airmail

Am 4. März 2017 um 20:10:56, Matthew Johnson via swift-evolution (swift-evolution at swift.org) schrieb:



Sent from my iPad

> On Mar 4, 2017, at 10:09 AM, Rien <Rien at Balancingrock.nl> wrote:
>  
>  
>> On 04 Mar 2017, at 16:01, Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
>>  
>> I have updated this proposal with a few more refinements based on yesterday’s discussion. You can find the final proposal on Github:
>>  
>> https://github.com/anandabits/swift-evolution/blob/scope-bounded-capabilities/proposals/NNNN-scope-bounded-capabilities.md.
>>  
>> Matthew
>>  
>>> On Mar 2, 2017, at 1:58 PM, Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
>>>  
>>> ...
>>> The rules which make up the essential complexity in Swift's access control system are:
>>>  
>>> • The default scope for all capabilites a declaration offers is module-wide (or submodule-wide in the future).
>>> • The scope of a capability may be modified by an explicit access modifier.
>>> • The scope of an additional capability is implicitly bounded by the scope of the basic capability.
>>> • The scope of an additional capability may not be explicitly specified as greater than that of the basic capability.
>>> • If no scope is explicitly provided for the basic capability and an additional capability is specified to be available outside the (sub)module the basic capability is also given the same availability.
>>> • The scope of a declaration (including all capabilities) may be bounded by the declaration of ancestor.
>  
> Do you mean: IS bounded by?

No, not necessarily. If the declaration is bounded to the module and all ancestors are public the ancestors don't bound really bound it. I suppose you could say the ancestor still provides a bound that is just never reached. I'm that sense, it depends on how you want to look at it. :)

>  
>  
>>> • The scope of a declaration may not be greater than the scope of the capabilities necessary to use that declaration: if you can't see a parameter type you can't call the function.
>>> Most of these rules already exist in Swift's access control system. There is one change and one addition:
>  
> Overall I think the draft is pretty solid.
> Imo this would give Swift the best available access control system I know of ;-)
> Thanks for your work on this!

I'm glad to hear you like it! Thanks! I'm hoping the core team is willing to review it for Swift 4 and feedback continues to be positive. It feels like something that should be done in Swift 4 if we're going to do it.

>  
> Regards,
> Rien
>  
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Balancingrock
> Project: http://swiftfire.nl
>  
>  
>  
>  
>  

_______________________________________________
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/20170305/dec80a19/attachment.html>