[swift-evolution] Protected access level / multiple class/struct/protocol APIs

[Diego Sánchez]

That's the key point.

"Protected" would increase the expressivity of the language by declaring
intent and exposing cleaner public APIs.

I don't think this idea should be dropped just because conscious
hacks/decisions
can workaround it, so big +1 for it.

2016-03-30 5:51 GMT+01:00 Thorsten Seitz via swift-evolution <
swift-evolution at swift.org>:

> I have no problems with "protected" members being made accessible in
> subclasses or extensions because this requires conscious decisions and
> actions to extend the API.
> Access levels are not there to protect against hacking, they are there to
> ensure that something can only be used through its given API. They are not
> there to restrict extending that API.
>
> Having said that I'd love to have "protected".
>
> -Thorsten
>
> > Am 30.03.2016 um 03:28 schrieb Joe Groff via swift-evolution <
> swift-evolution at swift.org>:
> >
> >
> >>> On Mar 29, 2016, at 6:18 PM, Joe Groff via swift-evolution <
> swift-evolution at swift.org> wrote:
> >>>
> >>>
> >>> On Mar 29, 2016, at 6:04 PM, Dietmar Planitzer via swift-evolution <
> swift-evolution at swift.org> wrote:
> >>>
> >>> Well that would be true if we assume that protected would work that
> way. Considering that this:
> >>>
> >>> private class A { … }
> >>>
> >>> public class B : A { … }
> >>>
> >>> is not allowed in Swift, I don’t see a good reason why an override of
> a protected method should be allowed to upgrade the access level to public.
> On the other hand this:
> >>>
> >>> public class A {
> >>>  private func foo() {
> >>>      print("A")
> >>>  }
> >>> }
> >>>
> >>> public class B : A {
> >>>  public override func foo() {
> >>>      print(“B”)
> >>>  }
> >>> }
> >>>
> >>> happens to actually work if both A and B are defined in the same file
> - which is rather unexpected. I would have expected that Swift would in
> general not allow overrides to upgrade the inherited access level. Eg
> exposing semantics which is embodied in a private or protected method
> should require a conscisous design decision and should require the designer
> to introduce a separate method name which is part of the public API. The
> public method can then call through to the private or protected method as
> needed.
> >>
> >> That would still be a toothless restriction, since a subclass could
> define a new method:
> >>
> >> public class B : A {
> >>  public func foo_() {
> >>      super.foo()
> >>  }
> >> }
> >>
> >> From an interface perspective, there's no difference between a subclass
> defining a new method or overriding a method that happens to be private to
> the base class.
> >
> > Extensions further dilute the enforceability of "protected", since
> anyone would be able to use an extension to dump methods into a class's
> namespace and access its supposedly-protected bits.
> >
> > -Joe
> > _______________________________________________
> > 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/20160330/9ee37f07/attachment.html>