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

[Daniel Leping]

For all thous who expresses thoughts like "the proposal is too much of a
complexity": first of all - I like the open approach of it. It's easily
extensible. After that - it gives one the flexibility. For the newbies
there are shortcut aliases if they don't want (can't) dig deeper at the
moment.

I think it's a good way to go, because we (the community) still haven't
figured out what we want to have at the end of the day. I mean we are all
talking about which keywords to use, but the ideology is not nailed down
yet... This way we can at least have a consistent model, easily stretchable
in the future releases (I hope one day we will come up with something that
we would like to put in stone). Until then - I choose flexibility.

On Sun, 5 Mar 2017 at 11:59 Adrian Zubarev via swift-evolution <
swift-evolution at swift.org> wrote:

> 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
>
> _______________________________________________
> 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/5e10ba31/attachment.html>