On Feb 14, 2017, at 11:46 PM, Jean-Daniel via swift-evolution
<swift-evolution@swift.org> wrote:
>>> Keeping with the spirit of Swift and staying consistent with its design, I
>>> see two plausible meanings for private:
>>>
>>> Private could mean either:
...
>>> (2) accessible only to the current type/scope and to extensions to that
>>> type that are in the current file.
>>
>> I think (2) is worth discussing. My 2 cents:
>>
>> Pros
>> • Solves a high percentage of use cases of fileprivate
>> • Type-scope proponents retain some of the safety
>>
>> Cons
>> • Less straight forward to explain
>> • Access to different type/scope in same file not possible anymore
>
> Which means that if we choose 2, we must keep fileprivate.
> Being able to access other type private members in the same file is an
> important feature that can’t be easily replaced, so it would badely break
> existing code if we remove it.
Yeah, I think you’re right, which sinks the whole idea: we should aim to
(re)simplify the access control model. (2) is also problematic because it
doesn’t allow the private members to be used by other things in the same file.
E.g. use a private member of Foo in an extension on String.
IMO, removing fileprivate and making private match Swift 2 semantics seems like
the more promising approach.
-Chris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
