[swift-evolution] [Review] SE-0119: Remove access modifiers from extensions

Xiaodi Wu xiaodi.wu at gmail.com
Wed Jul 13 10:46:11 CDT 2016

On Wed, Jul 13, 2016 at 4:04 AM, Rod Brown via swift-evolution <
swift-evolution at swift.org> wrote:

> Proposal link:
> https://github.com/apple/swift-evolution/blob/master/proposals/0119-extensions-access-modifiers.md
> * What is your evaluation of the proposal?
> -1. Extensions appear to me to follow the access control of the rest of
> Swift: Implicit to the type you are extending, and you can either / both
> declare as part of the extension declaration or on the method. I don’t see
> how this is confusing, and I expect people will be more confused that
> extensions don’t follow the convention of the rest of Swift for Access
> Control.

So, actually, the proposal is correct that extensions (at least once
fileprivate/private is implemented) don't follow the access control rules
for the rest of Swift. There is a problem to be addressed. However, I agree
that this proposal hasn't identified the issue or adequately explained how
the solution solves it. Here's the problem I'm thinking of:

public struct foo {
  func frobnicate() { } // implicitly internal

public struct bar { }
public extension bar {
  func frobnicate() { } // implicitly public
  // at least, according to the revised rules explained in SE-0025

This is an inconsistency that may (and IMO, really is) worth addressing. If
there's adequate interest, I can circulate a draft with a proposed solution
I have in mind.

> * Is the problem being addressed significant enough to warrant a change to
> Swift?
> I don’t think this warrants a change.
> * Does this proposal fit well with the feel and direction of Swift?
> No. This seems to go against the direction of Swift.
> * If you have used other languages or libraries with a similar feature,
> how do you feel that this proposal compares to those?
> No.
> * How much effort did you put into your review? A glance, a quick reading,
> or an in-depth study?
> A reading of the proposal.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160713/28cafa3d/attachment.html>

More information about the swift-evolution mailing list