The purpose of an implicit internal, at least a big one, is for progressive disclosure. It allows learners to write useful types (and indeed entire apps) before they learn about access levels. Of the existing access levels only internal fits the bill.
I do agree that for optimal style internal should be written out; indeed I write out the access level for each member. I really don't see a need to force everyone to adopt that style though, as long as we have one consistent rule for what the default is. On Mon, Feb 13, 2017 at 07:38 Karl Wagner via swift-evolution < swift-evolution@swift.org> wrote: > On 13 Feb 2017, at 14:24, Adrian Zubarev via swift-evolution < > swift-evolution@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 > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
