> On Jan 25, 2017, at 14:34, Robert Widmann via swift-evolution 
> <swift-evolution@swift.org> wrote:
> Responding on the pro side, but I don't endorse this proposal without more 
> details:
> ~Robert Widmann
> 2017/01/25 13:40、Xiaodi Wu <xiaodi...@gmail.com <mailto:xiaodi...@gmail.com>> 
> のメッセージ:
>> This is contrary to several deliberate design decisions, if I understand 
>> correctly.
>> First, revisions to visibility rules in the Swift 3 timeline were made with 
>> the deliberate intention that it should be possible to model greater 
>> visibility within a type (e.g. public members) without actually exporting 
>> that type. As Swift does not have optional warnings that can be turned off, 
>> it would be incongruous if the language also warned users away from creating 
>> internal types or variables before they are used. Unlike warnings about 
>> unused variables within a scope, which are by definition local, a warning 
>> such as proposed would be much more disruptive.
> That decision wasn't really one made to support a deliberate design, but to 
> help make migration of fileprivate easier IIRC (Jordan Rose probably 
> remembers better than I do of the conversation we had about this).

Saying it's about "migration" is disingenuous. The particular language in 

        • The compiler should not warn when a broader level of access control 
is used within a type with more restrictive access, such as internal within a 
private type. This allows the designer of the type to select the access they 
would use were they to make the type more widely accessible. (The members still 
cannot be accessed outside the enclosing lexical scope because the type itself 
is still restricted, i.e. outside code will never encounter a value of that 

That is, this was a change made to support local design that happened to 
simplify the rules around access, particularly

        • The default level of access control anywhere is internal.

So it still qualifies as "deliberate design".

swift-evolution mailing list

Reply via email to