Re: [swift-evolution] Simplifying Default Access Modifiers

-1. Aside from everyone being used to current behavior that I personally do find more logical since it prevents you from accidently exposing internal members via public API, the migrator won't have a choice but to slap "internal" everywhere during migration and like there are now projects full

Re: [swift-evolution] Simplifying Default Access Modifiers

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

Re: [swift-evolution] Simplifying Default Access Modifiers

It bears mentioning that it does _not_ formally work this way with fileprivate or private types. The default access level for members is always internal. This was a deliberate change I suggested for SE-0025 and is new for Swift 3. It's just also the case that the rules were relaxed to allow you to

Re: [swift-evolution] Simplifying Default Access Modifiers

Sent from my iPad > On Feb 13, 2017, at 3:02 AM, Jonathan Hull via swift-evolution > wrote: > > I would like to propose a change to the default access modifier within an > enclosing scope. The default for top level definitions would stay internal, > but anything

Re: [swift-evolution] Simplifying Default Access Modifiers

> On 13 Feb 2017, at 14:24, Adrian Zubarev via swift-evolution > 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

Re: [swift-evolution] Simplifying Default Access Modifiers

I think having a different default access for nested-scope adds a significant amount of cognitive complexity for not much value. I understand that structs as nested types are often used to communicate values outside the score (internal even), so public will be required often in these cases.

Re: [swift-evolution] Simplifying Default Access Modifiers

–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

Re: [swift-evolution] Simplifying Default Access Modifiers

+1 I think this is actually what most people would intuitively expect anyway. Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl > On 13 Feb 2017, at 10:02, Jonathan Hull via swift-evolution

[swift-evolution] Simplifying Default Access Modifiers

I would like to propose a change to the default access modifier within an enclosing scope. The default for top level definitions would stay internal, but anything within a scope would by default have the same visibility as it’s enclosing scope. The main reason for this is