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

Let me bump this thread. How do we move forward? Here's an interface of another Swift class I've just made (slowly rewriting my Obj-C components to Swift here): public class SoloContainerViewController: UIViewController { private var _contentViewController: UIViewController? public

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

>> My point is that "protected" *isn't* access control. If we added it, it >> would have to be as an independent modifier. Private/internal/public >> fundamentally affect semantics—private and internal code is only accessible >> within a module, so we have full knowledge of their use sites at

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

> Am 31.03.2016 um 17:51 schrieb Joe Groff : > >> >> On Mar 30, 2016, at 11:31 PM, Thorsten Seitz wrote: >> >> >> >> Am 31. März 2016 um 05:15 schrieb Andrey Tarantsov via swift-evolution >> : >> The problem with

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

> On Mar 30, 2016, at 11:31 PM, Thorsten Seitz wrote: > > > > Am 31. März 2016 um 05:15 schrieb Andrey Tarantsov via swift-evolution > : > >>> The problem with protected is that it provides virtually no protection at >>> all; you can

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

___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

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

> The problem with protected is that it provides virtually no protection at > all; you can trivially expose it in a derived 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

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

> On Mar 29, 2016, at 18:28, Joe Groff wrote: > > >> On Mar 29, 2016, at 6:18 PM, Joe Groff via swift-evolution >> wrote: >> >>> >>> On Mar 29, 2016, at 6:04 PM, Dietmar Planitzer via swift-evolution >>> wrote: >>>

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

> On Mar 29, 2016, at 18:18, Joe Groff wrote: > > >> On Mar 29, 2016, at 6:04 PM, Dietmar Planitzer via swift-evolution >> wrote: >> >> Well that would be true if we assume that protected would work that way. >> Considering that this: >> >>

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

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

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

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

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

> On Mar 29, 2016, at 6:18 PM, Joe Groff via swift-evolution > wrote: > >> >> On Mar 29, 2016, at 6:04 PM, Dietmar Planitzer via swift-evolution >> wrote: >> >> Well that would be true if we assume that protected would work that way.

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

> On Mar 29, 2016, at 6:04 PM, Dietmar Planitzer via swift-evolution > 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,

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

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

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

I tend to think an intended use annotation that could also be used in Obj-C would be better than protected. The problem with protected is that it provides virtually no protection at all; you can trivially expose it in a derived class, e.g.: class Protected { protected func onlyDerived() { ... }

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

A more sophisticated rights system isn't necessary, but actually, we could build everything with nothing but "public", so it is always a compromise between simplicity and expressiveness… Imho it would be nice to be able to mark a method that is only there to be overridden and should never be