[swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions
xiaodi.wu at gmail.com
Sat Apr 22 16:55:49 CDT 2017
On Sat, Apr 22, 2017 at 4:05 PM, Jose Cheyo Jimenez <cheyo at masters3d.com>
> On Apr 22, 2017, at 12:30 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> On Sat, Apr 22, 2017 at 11:51 AM, Jose Cheyo Jimenez via swift-evolution <
> swift-evolution at swift.org> wrote:
>> On Apr 21, 2017, at 8:41 PM, BJ Homer via swift-evolution <
>> swift-evolution at swift.org> wrote:
>> The "Access Control" section of the Swift 3 book says the following:
>> You can mark an extension with an explicit access-level modifier (for
>> example, private extension) to set a *new default access level* for all
>> members defined within the extension.
>> The behavior of "private extension" in Swift 3 was a deviation from that
>> model, justified because "private" as a default would have meant that
>> nothing in the extension could ever be called. But it was still contrary to
>> the model suggested by the Swift documentation.
>> Given the highly restrictive behavior of "private" in Swift 3 and the
>> documentation quoted above, it seems unlikely that a developer would
>> intentionally use "private extension" to mean "please make all this stuff
>> visible to the entire file"—it would have worked, but it seems an odd way
>> to write it. If that were the intention, I think "fileprivate extension"
>> would have been more likely.
>> I think the change to the behavior of "private extension" is in line with
>> the model proposed by SE-0169, in line with the documented behavior of
>> access control on extensions, and in line with user expectations.
>> I understand your point. Another aspect of SE-0169 is that fileprivate
>> should be more rare and thus meaningful when used. The current behavior
>> stays true to the goal of making fileprivate rare.
>> A top level private scope is effectively fileprivate so it is not totally
>> weird for the extension members to inherit the top level private scope.
>> When extensions gain the ability to contain properties, we should not
>> allow the access level modifiers to the extensions in the same way protocol
>> extensions prohibit its use.
> That idea would be my preference too, but it has been already written up
> as a proposal, considered, and rejected.
> Properties in extensions? AKA partials ? I was thinking disallow only when
> properties are introduced in the extension not in general.
No, disallowing access modifiers on extensions.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution