> On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> On 11 Apr 2017, at 09:40, John McCall <rjmcc...@apple.com 
> <mailto:rjmcc...@apple.com>> wrote:
> 
>>> On Apr 11, 2017, at 1:34 AM, David Hart via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Sent from my iPhone
>>> On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>>> I have not voted in favor or against the proposal. I have been reading a 
>>>> lot of responses but I agree with Tony. 
>>>> 
>>>> When I started reading the proposal everything was more or less fine half 
>>>> way through the proposal because it was reverting private to fileprivate 
>>>> between the type and its extensions within the same file. I said, if you 
>>>> think of the type and its extensions as a unit then it makes sense. I can 
>>>> explain that. 
>>>> 
>>>> Then it started describing a different behavior among the extensions 
>>>> located in a file separate from the file containing the definition of the 
>>>> type. That just started a whole debate inside my head and I understand the 
>>>> passionate responses on both sides. 
>>>> 
>>>> But then I imagined myself explaining this to someone new to Swift and it 
>>>> just doesn't seem right. If it becomes convoluted then that's a red flag 
>>>> that it does not belong in Swift. 
>>> 
>>> I understand what you are saying and I wouldn't be against relaxing that 
>>> requirement (not talking for Chris here).
>>> 
>>> The model would change from "Types share scopes with their extensions in 
>>> the same file the type was defined" to "Types and their extensions share 
>>> the same scope in each file".
>> 
>> Oh, I had missed that somehow.  I agree that that is a very strange rule.  
>> Do you know why it was proposed that way?
> 
> We had to take a stance and Chris seemed to prefer the rule that was 
> proposed. I didn't press because I'm sure he has reasons for preferring it 
> that way. But I have a preference for generalizing visibility to all 
> extensions, even to those in a different file than the type.

I think there is a technical limitation if the visibility goes beyond the 
compilation unit (unless whole module optimization is turned on).
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to