Re: [swift-evolution] Protected Access

While that’s true, it’s pretty clearly a hack. Having this built into the language would not only be a lot more elegant, but could also prevent override-only methods from showing up in Xcode’s autocomplete. Charles > On Oct 7, 2016, at 6:36 PM, Callionica (Swift) via swift-evolution >

Re: [swift-evolution] Protected Access

Jon--earlier in the week, there was another thread which once against raised the idea of internal or private protocol conformances; would that be another way of addressing your use case here? On Fri, Oct 7, 2016 at 6:36 PM, Callionica (Swift) via swift-evolution < swift-evolution@swift.org>

Re: [swift-evolution] Protected Access

For overridable, but not callable, you can use the technique outlined at http://www.callionica.com/developer/#swift-protected (give your method a parameter of a type that only the base class can create) On Friday, October 7, 2016, Jonathan Hull via swift-evolution < swift-evolution@swift.org>

Re: [swift-evolution] Protected Access

I agree with and also feel access modifiers / controls are missing and the ones we have may not be the best if you factor in these additional needs. I also agree that I would prefer the discussion be more focused on this type of thing. Thanks for capturing some of the things you have seen (I have

[swift-evolution] Protected Access

The discussion of private/fileprivate reminded me of other access modifier issues that have been bugging me. I agree that the old system is better, but I am ambivalent about changing it back… What I pretty much constantly want is an access modifier which lets me access something from an

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