[swift-evolution] Simplifying Default Access Modifiers

Karl Wagner razielim at gmail.com
Mon Feb 13 07:38:34 CST 2017

> On 13 Feb 2017, at 14:24, Adrian Zubarev via swift-evolution <swift-evolution at swift.org> wrote:
> –1 for me.
> IMO the current behavior reduces all that internal noise in large projects, where the author only makes a small part of the API public. Furthermore this will break the implicit initializer on structs and make it implicitly public. Leaving the initializer as internal while everything else is public as a workaround would be inconsistent solution, so that’s a no go. Personally I think that will introduce more noise than the current behavior, because we’ll have to repeat internal all over the place in large projects. So in my eyes this would be a regression.
> P.S.: I’m curious what the core team has to say about this.
I actually think “internal” is something which is worth calling out explicitly. It says that something is visible to other types in the project but not generally exported as part of the library’s API, which isn’t necessarily obvious. Implicit initialisers can be defined as having the same visibility as the type which they initialise.

Would be a huge source-breaking change though. I’m not sure anybody’s really 100% happy with our access modifiers, but it’s such a big change the core-team would understandably be reluctant to do it.

- Karl

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170213/5cb7f303/attachment.html>

More information about the swift-evolution mailing list