I think at this point we really need to build a concrete catalog of "warts" that cause implementation details to leak out of a module to consumers of a module (by extension submodule). I think that is the first things that should be looked at when considering making any changes to the access controls. I have a few code examples that I likely can pull together from real code that highlights some issues and I bet others do as well.
If we can collect these and look at them more holistically it would be helpful. I think email is likely a week way to do this... hum... -Shawn On Fri, Dec 2, 2016 at 7:51 AM Tino Heth via swift-evolution < [email protected]> wrote: > Well, anyways, with Swift 3 it no longer is as simple as it is in Obj-C. > New modifiers were introduced by request. I feel it's good and means > everybody agrees Obj-C modifiers aren't sufficient for Swift. > > Well… no ;-) > I'm not sure if there is a single thing in the universe where really > everybody agrees on — right now, there is nothing more than a small group > that has a vague agreement that there is room for improvement with the > current access levels; most Swift users aren't even aware of this > discussion at all (and most likely never will be ;-) > [In situations like this, I really dislike the restrictions of this > medium… with something like a Wiki, it would be much easier to set up a > table so that we could at least collect the opinions from the people > discussing now.] > > What I mean, initial arguments should apply no more and I hope Apple will > not be too rigid with current status. > > I agree on the latter — but it might be the case that fundamental changes > to Swift won't be considered anymore > > What I mean, though, the new introductions of access modifiers feel quite > some "patchy". > > Yes… but imho your suggestion which adds additional levels makes it even > more patchy: > "protected" might be familiar to some developers, but "inner" is just a > new magic word tacked onto the language. > For me, this is actually the worst direction to take: Adding more and more > new modifiers instead of really rethinking the topic from scratch. > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
