Idea: Public Access Modifier Respected in Type Definition

Evolution Discussion
1

When declaring a public class or struct the properties still default to internal.

public final class NewType {
	/// This property defaults to internal.
	var property: Any?
}

This is not the same for a public extension on the type, where then the access modifier is respected for any function or calculated property within the extension.

public extension NewType {
	/// This function inherits the public modifier.
	func function() {
	}
}

I dislike this inconsistency, and I frequently find that when using my dynamic frameworks my code will not compile, and it will be due to my accidentally writing a public struct but not declaring the properties public.

I believe in the idea that explicitly stating the access modifier leads to more legible code, but in my opinion it can be overdone, and I much prefer to explicitly state my intentions in the modifier on the definition or extension. For example:

public struct Coordinate {
	/// Should default to public.
	let latitude: Double
	/// Should default to public.
	let longitude: Double
	/// Should default to public
	init?(latitude: Double, longitude: Double) {
		guard validate(latitude: latitude, longitude: longitude) else { return nil }
		…
	}
}
internal extension Coordinate {
	/// Convenience initialiser to me used internally within the module.
	init(coordinate: CLLocationCoordinate2D) {
		…
	}
}
private extension Coordinate {
	/// Private validation of the coordinate.
	func validate(latitude: Double, longitude: Double) -> Bool {
		…
	}
}

This is legible and intuitive. The current behaviour is not.

2

+1000

This is the way it always should have worked… and it is the way my brain still expects it to work. All of the extraneous “Public”s clutter the code and make it much more difficult to read. Without it, the relatively few properties marked Internal or Private stand out.

I know there is the argument about making people think about whether they want to expose each item… but it doesn’t work that way. Once you assign someone a rote task (assigning Public to most of the things), you lose the effect of having them think. From a cognitive psychology lens, when you give the brain a number of decisions to make in a row that are very similar, it will naturally make that task more efficient by automating as much of it as possible (i.e. thinking about it less). Mistakes become much more likely as a result.

Tl;dr: Despite the myth/intention that the current setup makes you think about the problem more, it actually does the opposite and leads to an increased risk of error.

Thanks,
Jon

···

On Sep 28, 2017, at 10:44 AM, James Valaitis via swift-evolution <swift-evolution@swift.org> wrote:

When declaring a public class or struct the properties still default to internal.

public final class NewType {
	/// This property defaults to internal.
	var property: Any?
}

This is not the same for a public extension on the type, where then the access modifier is respected for any function or calculated property within the extension.

public extension NewType {
	/// This function inherits the public modifier.
	func function() {
	}
}

I dislike this inconsistency, and I frequently find that when using my dynamic frameworks my code will not compile, and it will be due to my accidentally writing a public struct but not declaring the properties public.

I believe in the idea that explicitly stating the access modifier leads to more legible code, but in my opinion it can be overdone, and I much prefer to explicitly state my intentions in the modifier on the definition or extension. For example:

public struct Coordinate {
	/// Should default to public.
	let latitude: Double
	/// Should default to public.
	let longitude: Double
	/// Should default to public
	init?(latitude: Double, longitude: Double) {
		guard validate(latitude: latitude, longitude: longitude) else { return nil }
		…
	}
}
internal extension Coordinate {
	/// Convenience initialiser to me used internally within the module.
	init(coordinate: CLLocationCoordinate2D) {
		…
	}
}
private extension Coordinate {
	/// Private validation of the coordinate.
	func validate(latitude: Double, longitude: Double) -> Bool {
		…
	}
}

This is legible and intuitive. The current behaviour is not.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

3

No please no, the ship is long sailed for this one. I wish I didn‘t messed up my proposal last year and that we completely got rid of the access modifiers before the `extension` keyword.

Huge -1

···

--
Adrian Zubarev
Sent with Airmail

Am 28. September 2017 um 19:44:25, James Valaitis via swift-evolution (swift-evolution@swift.org(mailto:swift-evolution@swift.org)) schrieb:

When declaring a public class or struct the properties still default to internal.

public final class NewType {
/// This property defaults to internal.
var property: Any?
}

This is not the same for a public extension on the type, where then the access modifier is respected for any function or calculated property within the extension.

public extension NewType {
/// This function inherits the public modifier.
func function() {
}
}

I dislike this inconsistency, and I frequently find that when using my dynamic frameworks my code will not compile, and it will be due to my accidentally writing a public struct but not declaring the properties public.

I believe in the idea that explicitly stating the access modifier leads to more legible code, but in my opinion it can be overdone, and I much prefer to explicitly state my intentions in the modifier on the definition or extension. For example:

public struct Coordinate {
/// Should default to public.
let latitude: Double
/// Should default to public.
let longitude: Double
/// Should default to public
init?(latitude: Double, longitude: Double) {
guard validate(latitude: latitude, longitude: longitude) else { return nil }
…
}
}
internal extension Coordinate {
/// Convenience initialiser to me used internally within the module.
init(coordinate: CLLocationCoordinate2D) {
…
}
}
private extension Coordinate {
/// Private validation of the coordinate.
func validate(latitude: Double, longitude: Double) -> Bool {
…
}
}

This is legible and intuitive. The current behaviour is not.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

4

I should also mention that this is from a class of error where it becomes more likely with expertise. Thus, the more you do it, and get used to doing it, the more your brain will automate the task. You see this type of thing pretty often with nurses, for example.

For anyone who would like a better understanding of the science behind designing to prevent errors, I recommend the book “Human Error” by James Reason.

Also "The Design of Everyday Things" by Don Norman has a pretty good chapter on the basics, and is much more accessible.

I really like that Swift attempts to do this! The use of forcing functions around optionals, for example, is brilliant. It is just that we are applying solutions rather haphazardly (without matching them to the underlying cause of error), and I think we can do better. That we are even considering these things is huge! I am just saying that there is an entire body of scientific research we can use to effectively accomplish this goal (and avoid known pitfalls)… we don’t have to reinvent the wheel.

Thanks,
Jon

···

On Sep 28, 2017, at 5:31 PM, Jonathan Hull via swift-evolution <swift-evolution@swift.org> wrote:

+1000

This is the way it always should have worked… and it is the way my brain still expects it to work. All of the extraneous “Public”s clutter the code and make it much more difficult to read. Without it, the relatively few properties marked Internal or Private stand out.

I know there is the argument about making people think about whether they want to expose each item… but it doesn’t work that way. Once you assign someone a rote task (assigning Public to most of the things), you lose the effect of having them think. From a cognitive psychology lens, when you give the brain a number of decisions to make in a row that are very similar, it will naturally make that task more efficient by automating as much of it as possible (i.e. thinking about it less). Mistakes become much more likely as a result.

Tl;dr: Despite the myth/intention that the current setup makes you think about the problem more, it actually does the opposite and leads to an increased risk of error.

Thanks,
Jon

On Sep 28, 2017, at 10:44 AM, James Valaitis via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

When declaring a public class or struct the properties still default to internal.

public final class NewType {
	/// This property defaults to internal.
	var property: Any?
}

This is not the same for a public extension on the type, where then the access modifier is respected for any function or calculated property within the extension.

public extension NewType {
	/// This function inherits the public modifier.
	func function() {
	}
}

I dislike this inconsistency, and I frequently find that when using my dynamic frameworks my code will not compile, and it will be due to my accidentally writing a public struct but not declaring the properties public.

I believe in the idea that explicitly stating the access modifier leads to more legible code, but in my opinion it can be overdone, and I much prefer to explicitly state my intentions in the modifier on the definition or extension. For example:

public struct Coordinate {
	/// Should default to public.
	let latitude: Double
	/// Should default to public.
	let longitude: Double
	/// Should default to public
	init?(latitude: Double, longitude: Double) {
		guard validate(latitude: latitude, longitude: longitude) else { return nil }
		…
	}
}
internal extension Coordinate {
	/// Convenience initialiser to me used internally within the module.
	init(coordinate: CLLocationCoordinate2D) {
		…
	}
}
private extension Coordinate {
	/// Private validation of the coordinate.
	func validate(latitude: Double, longitude: Double) -> Bool {
		…
	}
}

This is legible and intuitive. The current behaviour is not.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

5

I don't want this to come across as though I'm trying to shut down
discussion (because it's not my place to do so), but a significant amount
of time was spent during the Swift 4 design phases debating how access
levels should work, decisions were made, and I think many of us would like
to move on and give time to other topics.

I'd encourage you to look back through the archives and familiarize
yourselves with the points made during that time. While it's always
possible, I think it's unlikely that there will be new evidence introduced
that would be so strong as to give the Swift team reason to, once again,
make major source-breaking changes to access levels as late as Swift 5.

···

On Thu, Sep 28, 2017 at 5:31 PM Jonathan Hull via swift-evolution < swift-evolution@swift.org> wrote:

+1000

This is the way it always should have worked… and it is the way my brain
still expects it to work. All of the extraneous “Public”s clutter the code
and make it much more difficult to read. Without it, the relatively few
properties marked Internal or Private stand out.

I know there is the argument about making people think about whether they
want to expose each item… but it doesn’t work that way. Once you assign
someone a rote task (assigning Public to most of the things), you lose the
effect of having them think. From a cognitive psychology lens, when you
give the brain a number of decisions to make in a row that are very
similar, it will naturally make that task more efficient by automating as
much of it as possible (i.e. thinking about it less). Mistakes become much
more likely as a result.

Tl;dr: Despite the* myth*/intention that the current setup makes you*
think about the problem more,* it actually does the* opposite* and leads
to an *increased risk of error*.

Thanks,
Jon

On Sep 28, 2017, at 10:44 AM, James Valaitis via swift-evolution < > swift-evolution@swift.org> wrote:

When declaring a public class or struct the properties still default to
internal.

public final class NewType {
/// This property defaults to internal.
var property: Any?
}

This is not the same for a public extension on the type, where then the
access modifier is respected for any function or calculated property within
the extension.

public extension NewType {
/// This function inherits the public modifier.
func function() {
}
}

I dislike this inconsistency, and I frequently find that when using my
dynamic frameworks my code will not compile, and it will be due to my
accidentally writing a public struct but not declaring the properties
public.

I believe in the idea that explicitly stating the access modifier leads to
more legible code, but in my opinion it can be overdone, and I much prefer
to explicitly state my intentions in the modifier on the definition or
extension. For example:

public struct Coordinate {
/// Should default to public.
let latitude: Double
/// Should default to public.
let longitude: Double
/// Should default to public
init?(latitude: Double, longitude: Double) {
guard validate(latitude: latitude, longitude: longitude) else { return nil
}
…
}
}
internal extension Coordinate {
/// Convenience initialiser to me used internally within the module.
init(coordinate: CLLocationCoordinate2D) {
…
}
}
private extension Coordinate {
/// Private validation of the coordinate.
func validate(latitude: Double, longitude: Double) -> Bool {
…
}
}

This is legible and intuitive. The current behaviour is not.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

6

I am grad if it is accepted.

I have two reasons.

(1)
I just recently confused visibility rule of extension which is different
from class/struct.

(2)
I often write many classes in only one application target in project first.
After code base grow, I often make new Framework target and move some
classes into this for organizing dependency and improving modularity.
At that time I need to write may `public` for classes and each func and
vars.
This is boring work.
If I need to write `public` only once for each classes, It is very
convenient.

···

--
omochimetaru

2017年9月29日(金) 10:05 Jonathan Hull via swift-evolution < swift-evolution@swift.org>:

I should also mention that this is from a class of error where it becomes
more likely with expertise. Thus, the more you do it, and get used to
doing it, the more your brain will automate the task. You see this type of
thing pretty often with nurses, for example.

For anyone who would like a better understanding of the science behind
designing to prevent errors, I recommend the book *“Human Error” *by*
James Reason*.

Also *"The Design of Everyday Things" *by* Don Norman* has a pretty good
chapter on the basics, and is much more accessible.

I really like that Swift attempts to do this! The use of forcing
functions around optionals, for example, is brilliant. It is just that we
are applying solutions rather haphazardly (without matching them to the
underlying cause of error), and I think we can do better. That we are even
considering these things is huge! I am just saying that there is an entire
body of scientific research we can use to effectively accomplish this goal
(and avoid known pitfalls)… we don’t have to reinvent the wheel.

Thanks,
Jon

On Sep 28, 2017, at 5:31 PM, Jonathan Hull via swift-evolution < > swift-evolution@swift.org> wrote:

+1000

This is the way it always should have worked… and it is the way my brain
still expects it to work. All of the extraneous “Public”s clutter the code
and make it much more difficult to read. Without it, the relatively few
properties marked Internal or Private stand out.

I know there is the argument about making people think about whether they
want to expose each item… but it doesn’t work that way. Once you assign
someone a rote task (assigning Public to most of the things), you lose the
effect of having them think. From a cognitive psychology lens, when you
give the brain a number of decisions to make in a row that are very
similar, it will naturally make that task more efficient by automating as
much of it as possible (i.e. thinking about it less). Mistakes become much
more likely as a result.

Tl;dr: Despite the* myth*/intention that the current setup makes you*
think about the problem more,* it actually does the* opposite* and leads
to an *increased risk of error*.

Thanks,
Jon

On Sep 28, 2017, at 10:44 AM, James Valaitis via swift-evolution < > swift-evolution@swift.org> wrote:

When declaring a public class or struct the properties still default to
internal.

public final class NewType {
/// This property defaults to internal.
var property: Any?
}

This is not the same for a public extension on the type, where then the
access modifier is respected for any function or calculated property within
the extension.

public extension NewType {
/// This function inherits the public modifier.
func function() {
}
}

I dislike this inconsistency, and I frequently find that when using my
dynamic frameworks my code will not compile, and it will be due to my
accidentally writing a public struct but not declaring the properties
public.

I believe in the idea that explicitly stating the access modifier leads to
more legible code, but in my opinion it can be overdone, and I much prefer
to explicitly state my intentions in the modifier on the definition or
extension. For example:

public struct Coordinate {
/// Should default to public.
let latitude: Double
/// Should default to public.
let longitude: Double
/// Should default to public
init?(latitude: Double, longitude: Double) {
guard validate(latitude: latitude, longitude: longitude) else { return nil
}
…
}
}
internal extension Coordinate {
/// Convenience initialiser to me used internally within the module.
init(coordinate: CLLocationCoordinate2D) {
…
}
}
private extension Coordinate {
/// Private validation of the coordinate.
func validate(latitude: Double, longitude: Double) -> Bool {
…
}
}

This is legible and intuitive. The current behaviour is not.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

7

I don't want this to come across as though I'm trying to shut down discussion (because it's not my place to do so), but a significant amount of time was spent during the Swift 4 design phases debating how access levels should work, decisions were made, and I think many of us would like to move on and give time to other topics.

I'd encourage you to look back through the archives and familiarize yourselves with the points made during that time. While it's always possible, I think it's unlikely that there will be new evidence introduced that would be so strong as to give the Swift team reason to, once again, make major source-breaking changes to access levels as late as Swift 5.

Tony, while I do understand and support your opinion and don't support the idea of this pitch, don't you think we should fix the huge inconsistency with 'private extension'?

private extension MyType {
  /// This method have fileprivate access level, not private
  func function() {...}
}

Such behavior had sense when extension was not able to keep private methods(who was able to see them then), but currently it is perfectly OK to have extension with only private methods in the same file with type.
And one can really use 'fileprivate extension' if this is an intention.
Existence of this inconsistency IMHO makes understanding of Swift access modifiers/levels even harder(especially for newcomers), adds point of confusion and even possible bugs(when code in same file accesses some method that really should be private), and removes a very useful feature to move some private methods to extensions.

Thank you.

Vladimir.

···

On 29.09.2017 3:56, Tony Allevato via swift-evolution wrote:

On Thu, Sep 28, 2017 at 5:31 PM Jonathan Hull via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

    +1000

    This is the way it always should have worked… and it is the way my brain still
    expects it to work. All of the extraneous “Public”s clutter the code and make it
    much more difficult to read. Without it, the relatively few properties marked
    Internal or Private stand out.

    I know there is the argument about making people think about whether they want to
    expose each item… but it doesn’t work that way. Once you assign someone a rote
    task (assigning Public to most of the things), you lose the effect of having them
    think. From a cognitive psychology lens, when you give the brain a number of
    decisions to make in a row that are very similar, it will naturally make that
    task more efficient by automating as much of it as possible (i.e. thinking about
    it less). Mistakes become much more likely as a result.

    Tl;dr: **Despite the*myth*/intention**that the current setup makes you*think
    about the problem more,* it actually does the*opposite* and leads to an
    *increased risk of error*.

    Thanks,
    Jon

    On Sep 28, 2017, at 10:44 AM, James Valaitis via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

    When declaring a public class or struct the properties still default to internal.
    ```
    public final class NewType {
    /// This property defaults to internal.
    var property: Any?
    }
    ```

    This is not the same for a public extension on the type, where then the access
    modifier is respected for any function or calculated property within the extension.
    ```
    public extension NewType {
    /// This function inherits the public modifier.
    func function() {
    }
    ```

    I dislike this inconsistency, and I frequently find that when using my dynamic
    frameworks my code will not compile, and it will be due to my accidentally
    writing a public struct but not declaring the properties public.

    I believe in the idea that explicitly stating the access modifier leads to more
    legible code, but in my opinion it can be overdone, and I much prefer to
    explicitly state my intentions in the modifier on the definition or extension.
    For example:

    ```
    public struct Coordinate {
    /// Should default to public.
    let latitude: Double
    /// Should default to public.
    let longitude: Double
    /// Should default to public
    init?(latitude: Double, longitude: Double) {
    guard validate(latitude: latitude, longitude: longitude) else { return nil }
    …
    }
    internal extension Coordinate {
    /// Convenience initialiser to me used internally within the module.
    init(coordinate: CLLocationCoordinate2D) {
    …
    }
    private extension Coordinate {
    /// Private validation of the coordinate.
    func validate(latitude: Double, longitude: Double) -> Bool {
    …
    }
    ```

    This is legible and intuitive. The current behaviour is not.

    _______________________________________________
    swift-evolution mailing list
    swift-evolution@swift.org <mailto:swift-evolution@swift.org>
    https://lists.swift.org/mailman/listinfo/swift-evolution

    _______________________________________________
    swift-evolution mailing list
    swift-evolution@swift.org <mailto:swift-evolution@swift.org>
    https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

8

Vladimir, I agree with you on that change, but it’s a separate topic from
this one.

Tony is absolutely correct that this topic has already been discussed. It
is a deliberate design decision that public types do not automatically
expose members without explicit access modifiers; this has been brought up
on this list, and it is clearly not in scope for discussion as no new
insight can arise this late in the game. The inconsistency with public
extensions was brought up, the proposed solution was to remove modifiers
for extensions, but this proposal was rejected. So, the final design is
what we have.

···

On Fri, Sep 29, 2017 at 05:47 Vladimir.S via swift-evolution < swift-evolution@swift.org> wrote:

On 29.09.2017 3:56, Tony Allevato via swift-evolution wrote:
> I don't want this to come across as though I'm trying to shut down
discussion
> (because it's not my place to do so), but a significant amount of time
was spent
> during the Swift 4 design phases debating how access levels should work,
decisions
> were made, and I think many of us would like to move on and give time to
other topics.
>
> I'd encourage you to look back through the archives and familiarize
yourselves with
> the points made during that time. While it's always possible, I think
it's unlikely
> that there will be new evidence introduced that would be so strong as to
give the
> Swift team reason to, once again, make major source-breaking changes to
access levels
> as late as Swift 5.

Tony, while I do understand and support your opinion and don't support the
idea of
this pitch, don't you think we should fix the huge inconsistency with
'private
extension'?

private extension MyType {
        /// This method have fileprivate access level, not private
        func function() {...}
}

Such behavior had sense when extension was not able to keep private
methods(who was
able to see them then), but currently it is perfectly OK to have extension
with only
private methods in the same file with type.
And one can really use 'fileprivate extension' if this is an intention.
Existence of this inconsistency IMHO makes understanding of Swift access
modifiers/levels even harder(especially for newcomers), adds point of
confusion and
even possible bugs(when code in same file accesses some method that really
should be
private), and removes a very useful feature to move some private methods
to extensions.

Thank you.

Vladimir.

>
>
>
> On Thu, Sep 28, 2017 at 5:31 PM Jonathan Hull via swift-evolution > > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
> +1000
>
> This is the way it always should have worked… and it is the way my
brain still
> expects it to work. All of the extraneous “Public”s clutter the
code and make it
> much more difficult to read. Without it, the relatively few
properties marked
> Internal or Private stand out.
>
> I know there is the argument about making people think about whether
they want to
> expose each item… but it doesn’t work that way. Once you assign
someone a rote
> task (assigning Public to most of the things), you lose the effect
of having them
> think. From a cognitive psychology lens, when you give the brain a
number of
> decisions to make in a row that are very similar, it will naturally
make that
> task more efficient by automating as much of it as possible (i.e.
thinking about
> it less). Mistakes become much more likely as a result.
>
> Tl;dr: **Despite the*myth*/intention**that the current setup makes
you*think
> about the problem more,* it actually does the*opposite* and leads to
an
> *increased risk of error*.
>
> Thanks,
> Jon
>
>
>> On Sep 28, 2017, at 10:44 AM, James Valaitis via swift-evolution > >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> > wrote:
>>
>> When declaring a public class or struct the properties still
default to internal.
>> ```
>> public final class NewType {
>> /// This property defaults to internal.
>> var property: Any?
>> }
>> ```
>>
>> This is not the same for a public extension on the type, where then
the access
>> modifier is respected for any function or calculated property
within the extension.
>> ```
>> public extension NewType {
>> /// This function inherits the public modifier.
>> func function() {
>> }
>> }
>> ```
>>
>> I dislike this inconsistency, and I frequently find that when using
my dynamic
>> frameworks my code will not compile, and it will be due to my
accidentally
>> writing a public struct but not declaring the properties public.
>>
>> I believe in the idea that explicitly stating the access modifier
leads to more
>> legible code, but in my opinion it can be overdone, and I much
prefer to
>> explicitly state my intentions in the modifier on the definition or
extension.
>> For example:
>>
>> ```
>> public struct Coordinate {
>> /// Should default to public.
>> let latitude: Double
>> /// Should default to public.
>> let longitude: Double
>> /// Should default to public
>> init?(latitude: Double, longitude: Double) {
>> guard validate(latitude: latitude, longitude: longitude) else {
return nil }
>> …
>> }
>> }
>> internal extension Coordinate {
>> /// Convenience initialiser to me used internally within the module.
>> init(coordinate: CLLocationCoordinate2D) {
>> …
>> }
>> }
>> private extension Coordinate {
>> /// Private validation of the coordinate.
>> func validate(latitude: Double, longitude: Double) -> Bool {
>> …
>> }
>> }
>> ```
>>
>> This is legible and intuitive. The current behaviour is not.
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

9

Agreed. The core team would only consider a refinement or change to access control if there were something actively broken that mattered for ABI stability.

-Chris

···

On Sep 29, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

Vladimir, I agree with you on that change, but it’s a separate topic from this one.

Tony is absolutely correct that this topic has already been discussed. It is a deliberate design decision that public types do not automatically expose members without explicit access modifiers; this has been brought up on this list, and it is clearly not in scope for discussion as no new insight can arise this late in the game. The inconsistency with public extensions was brought up, the proposed solution was to remove modifiers for extensions, but this proposal was rejected. So, the final design is what we have.

10

Vladimir, I agree with you on that change, but it’s a separate topic from this one.

Tony is absolutely correct that this topic has already been discussed. It is a deliberate design decision that public types do not automatically expose members without explicit access modifiers; this has been brought up on this list, and it is clearly not in scope for discussion as no new insight can arise this late in the game. The inconsistency with public extensions was brought up, the proposed solution was to remove modifiers for extensions, but this proposal was rejected. So, the final design is what we have.

Agreed. The core team would only consider a refinement or change to access control if there were something actively broken that mattered for ABI stability.

So we have to live with *protected* extension inconsistency for very long time just because core team don't want to even discuss _this particular_ inconsistency(when access level in *private extension* must be private, not fileprivate)?

Yes, we decided that access level for extension will mean a default and top most access level for nested methods, OK. But even in this rule, which already differ from access modifiers for types, we have another one special case for 'private extension'.

Don't you think this is not normal situation and actually there IMO can't be any reason to keep this bug-producing inconsistency in Swift? (especially given Swift 5 seems like is a last moment to fix this)

Vladimir.

···

On 01.10.2017 1:18, Chris Lattner wrote:

On Sep 29, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

-Chris

11

I hate to say it but I'm inclined to agree with Vladimir on this. "private extension" has a useful meaning now distinct from "fileprivate extension", and it was an oversight that SE-0169 <https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md&gt; didn't include a fix here. On this very narrow, very specific access control issue I think it would still be worth discussing; like Xiaodi said it's not related to James' original thread-starter.

(I maintain that the current model does not include a special case; it simply means the 'private' is resolved at the level of the extension rather than the level of its members. But that isn't what people expect and it's not as useful.)

I agree that changing the behavior of all access modifiers on extensions is out of scope. (I also agree that it is a bad idea. Sorry, James, but wanting 'pubic' here indicates that your mental model of extensions does not match what Swift is actually doing, and that could get you into trouble.)

Jordan

···

On Oct 2, 2017, at 03:25, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:

On 01.10.2017 1:18, Chris Lattner wrote:

On Sep 29, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

Vladimir, I agree with you on that change, but it’s a separate topic from this one.

Tony is absolutely correct that this topic has already been discussed. It is a deliberate design decision that public types do not automatically expose members without explicit access modifiers; this has been brought up on this list, and it is clearly not in scope for discussion as no new insight can arise this late in the game. The inconsistency with public extensions was brought up, the proposed solution was to remove modifiers for extensions, but this proposal was rejected. So, the final design is what we have.

Agreed. The core team would only consider a refinement or change to access control if there were something actively broken that mattered for ABI stability.

So we have to live with *protected* extension inconsistency for very long time just because core team don't want to even discuss _this particular_ inconsistency(when access level in *private extension* must be private, not fileprivate)?

Yes, we decided that access level for extension will mean a default and top most access level for nested methods, OK. But even in this rule, which already differ from access modifiers for types, we have another one special case for 'private extension'.

Don't you think this is not normal situation and actually there IMO can't be any reason to keep this bug-producing inconsistency in Swift? (especially given Swift 5 seems like is a last moment to fix this)

12

I am not in favor of including a special case for “private extension” because like Jordan said, private is resolved at the level of the extension which is always top level currently. A change would make sense if we start allowing extensions that are not top level. Anything private that is top level is equivalent to fileprivate so why should “private extension” be any different?

This is only confusing if people start mixing “fileprivate extension” and “private extension” in the same code base.

We have a SwiftLint rule for this situation:
https://github.com/realm/SwiftLint/blame/master/Source/SwiftLintFramework/Rules/PrivateOverFilePrivateRule.swift

Alternatively you can enforce no extensions :)
https://github.com/realm/SwiftLint/blob/master/Source/SwiftLintFramework/Rules/NoExtensionAccessModifierRule.swift

“"There is no solution that will make everyone happy: maintaining the status quo makes “fileprivate” too common and therefore not meaningful when it occurs in source;”"
https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000357.html

···

On Oct 2, 2017, at 5:33 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:

On Oct 2, 2017, at 03:25, Vladimir.S via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On 01.10.2017 1:18, Chris Lattner wrote:

On Sep 29, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Vladimir, I agree with you on that change, but it’s a separate topic from this one.

Tony is absolutely correct that this topic has already been discussed. It is a deliberate design decision that public types do not automatically expose members without explicit access modifiers; this has been brought up on this list, and it is clearly not in scope for discussion as no new insight can arise this late in the game. The inconsistency with public extensions was brought up, the proposed solution was to remove modifiers for extensions, but this proposal was rejected. So, the final design is what we have.

Agreed. The core team would only consider a refinement or change to access control if there were something actively broken that mattered for ABI stability.

So we have to live with *protected* extension inconsistency for very long time just because core team don't want to even discuss _this particular_ inconsistency(when access level in *private extension* must be private, not fileprivate)?

Yes, we decided that access level for extension will mean a default and top most access level for nested methods, OK. But even in this rule, which already differ from access modifiers for types, we have another one special case for 'private extension'.

Don't you think this is not normal situation and actually there IMO can't be any reason to keep this bug-producing inconsistency in Swift? (especially given Swift 5 seems like is a last moment to fix this)

I hate to say it but I'm inclined to agree with Vladimir on this. "private extension" has a useful meaning now distinct from "fileprivate extension", and it was an oversight that SE-0169 <https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md&gt; didn't include a fix here. On this very narrow, very specific access control issue I think it would still be worth discussing; like Xiaodi said it's not related to James' original thread-starter.

(I maintain that the current model does not include a special case; it simply means the 'private' is resolved at the level of the extension rather than the level of its members. But that isn't what people expect and it's not as useful.)

I agree that changing the behavior of all access modifiers on extensions is out of scope. (I also agree that it is a bad idea. Sorry, James, but wanting 'pubic' here indicates that your mental model of extensions does not match what Swift is actually doing, and that could get you into trouble.)

Jordan

13

Vladimir, I agree with you on that change, but it’s a separate topic from this one.

Tony is absolutely correct that this topic has already been discussed. It is a deliberate design decision that public types do not automatically expose members without explicit access modifiers; this has been brought up on this list, and it is clearly not in scope for discussion as no new insight can arise this late in the game. The inconsistency with public extensions was brought up, the proposed solution was to remove modifiers for extensions, but this proposal was rejected. So, the final design is what we have.

Agreed. The core team would only consider a refinement or change to access control if there were something actively broken that mattered for ABI stability.

So we have to live with *protected* extension inconsistency for very long time just because core team don't want to even discuss _this particular_ inconsistency(when access level in *private extension* must be private, not fileprivate)?

Yes, we decided that access level for extension will mean a default and top most access level for nested methods, OK. But even in this rule, which already differ from access modifiers for types, we have another one special case for 'private extension'.

Don't you think this is not normal situation and actually there IMO can't be any reason to keep this bug-producing inconsistency in Swift? (especially given Swift 5 seems like is a last moment to fix this)

I hate to say it but I'm inclined to agree with Vladimir on this. "private extension" has a useful meaning now distinct from "fileprivate extension", and it was an oversight that SE-0169 didn't include a fix here. On this very narrow, very specific access control issue I think it would still be worth discussing; like Xiaodi said it's not related to James' original thread-starter.

I agree with this in principle but would not want to see it become a slippery slope back into extremely long access control discussions.

···

Sent from my iPad

On Oct 2, 2017, at 7:33 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:

On Oct 2, 2017, at 03:25, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:
On 01.10.2017 1:18, Chris Lattner wrote:

On Sep 29, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

(I maintain that the current model does not include a special case; it simply means the 'private' is resolved at the level of the extension rather than the level of its members. But that isn't what people expect and it's not as useful.)

I agree that changing the behavior of all access modifiers on extensions is out of scope. (I also agree that it is a bad idea. Sorry, James, but wanting 'pubic' here indicates that your mental model of extensions does not match what Swift is actually doing, and that could get you into trouble.)

Jordan

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

14

Ok, I admit I just didn’t want to think about access control anymore after laster year’s excitement :-)

That said, it seems that there is broad support for considering a refinement here, and I’m happy to get out of the way and let you guys make Swift better. :-) Thanks!

-Chris

···

On Oct 2, 2017, at 5:33 PM, Jordan Rose <jordan_rose@apple.com> wrote:

Don't you think this is not normal situation and actually there IMO can't be any reason to keep this bug-producing inconsistency in Swift? (especially given Swift 5 seems like is a last moment to fix this)

I hate to say it but I'm inclined to agree with Vladimir on this. "private extension" has a useful meaning now distinct from "fileprivate extension", and it was an oversight that SE-0169 <https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md&gt; didn't include a fix here. On this very narrow, very specific access control issue I think it would still be worth discussing; like Xiaodi said it's not related to James' original thread-starter.

15

Two weeks ago I had a fairly strong opinion about “private extension”
behavior. After following this discussion, I now have no opinion on the
matter.

I would summarize the points on both sides as follows:

For the change:
• It is surprising to many people that members of a private extension are
implicitly fileprivate.
• There is currently no way to make an extension whose members default to
private.

Against the change:
• The proposal is source-breaking.
• The proposal makes “fileprivate” more common.
• A private extension and a (top-level) private type both currently have
implicitly fileprivate members. The proposal breaks that symmetry.

Notable questions:
• Currently “open” cannot be applied to an extension at all, should we
allow it?
• Might we ever want to allow nested (non-top level) extensions, and if so
how should access levels on them work?

Nevin

16

It's fair to be against this change, but I want to point out that neither of these are "special cases". Instead it's "access is resolved at the level of extension and then applied to the member" vs. "access is applied to the members and then resolved".

Jordan

···

On Oct 2, 2017, at 18:06, Jose Cheyo Jimenez <cheyo@masters3d.com> wrote:

On Oct 2, 2017, at 5:33 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Oct 2, 2017, at 03:25, Vladimir.S via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On 01.10.2017 1:18, Chris Lattner wrote:

On Sep 29, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Vladimir, I agree with you on that change, but it’s a separate topic from this one.

Tony is absolutely correct that this topic has already been discussed. It is a deliberate design decision that public types do not automatically expose members without explicit access modifiers; this has been brought up on this list, and it is clearly not in scope for discussion as no new insight can arise this late in the game. The inconsistency with public extensions was brought up, the proposed solution was to remove modifiers for extensions, but this proposal was rejected. So, the final design is what we have.

Agreed. The core team would only consider a refinement or change to access control if there were something actively broken that mattered for ABI stability.

So we have to live with *protected* extension inconsistency for very long time just because core team don't want to even discuss _this particular_ inconsistency(when access level in *private extension* must be private, not fileprivate)?

Yes, we decided that access level for extension will mean a default and top most access level for nested methods, OK. But even in this rule, which already differ from access modifiers for types, we have another one special case for 'private extension'.

Don't you think this is not normal situation and actually there IMO can't be any reason to keep this bug-producing inconsistency in Swift? (especially given Swift 5 seems like is a last moment to fix this)

I hate to say it but I'm inclined to agree with Vladimir on this. "private extension" has a useful meaning now distinct from "fileprivate extension", and it was an oversight that SE-0169 <https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md&gt; didn't include a fix here. On this very narrow, very specific access control issue I think it would still be worth discussing; like Xiaodi said it's not related to James' original thread-starter.

(I maintain that the current model does not include a special case; it simply means the 'private' is resolved at the level of the extension rather than the level of its members. But that isn't what people expect and it's not as useful.)

I agree that changing the behavior of all access modifiers on extensions is out of scope. (I also agree that it is a bad idea. Sorry, James, but wanting 'pubic' here indicates that your mental model of extensions does not match what Swift is actually doing, and that could get you into trouble.)

Jordan

I am not in favor of including a special case for “private extension” because like Jordan said, private is resolved at the level of the extension which is always top level currently. A change would make sense if we start allowing extensions that are not top level. Anything private that is top level is equivalent to fileprivate so why should “private extension” be any different?

17

Sent from my iPad

Vladimir, I agree with you on that change, but it’s a separate topic from
this one.

Tony is absolutely correct that this topic has already been discussed. It
is a deliberate design decision that public types do not automatically
expose members without explicit access modifiers; this has been brought up
on this list, and it is clearly not in scope for discussion as no new
insight can arise this late in the game. The inconsistency with public
extensions was brought up, the proposed solution was to remove modifiers
for extensions, but this proposal was rejected. So, the final design is
what we have.

Agreed. The core team would only consider a refinement or change to
access control if there were something actively broken that mattered for
ABI stability.

So we have to live with *protected* extension inconsistency for very long
time just because core team don't want to even discuss _this particular_
inconsistency(when access level in *private extension* must be private, not
fileprivate)?

Yes, we decided that access level for extension will mean a default and
top most access level for nested methods, OK. But even in this rule, which
already differ from access modifiers for types, we have another one special
case for 'private extension'.

Don't you think this is not normal situation and actually there IMO can't
be any reason to keep this bug-producing inconsistency in Swift?
(especially given Swift 5 seems like is a last moment to fix this)

I hate to say it but I'm inclined to agree with Vladimir on this. "private
extension" has a useful meaning now distinct from "fileprivate extension",
and it was an oversight that SE-0169
<https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md&gt; didn't
include a fix here. On this *very narrow, very specific *access control
issue I think it would still be worth discussing; like Xiaodi said it's not
related to James' original thread-starter.

I agree with this in principle but would not want to see it become a
slippery slope back into extremely long access control discussions.

As I've said elsewhere, I too agree with this in principle. I agree with
Jordan that the current state of things is justifiable but the alternative
would be somewhat superior, agree that in a vacuum this very narrow and
specific discussion might be warranted, and agree also that this could be a
very slippery slide down a very steep slope.

···

On Mon, Oct 2, 2017 at 9:16 PM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote:

On Oct 2, 2017, at 7:33 PM, Jordan Rose via swift-evolution < > swift-evolution@swift.org> wrote:
On Oct 2, 2017, at 03:25, Vladimir.S via swift-evolution < > swift-evolution@swift.org> wrote:
On 01.10.2017 1:18, Chris Lattner wrote:
On Sep 29, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote:

(I maintain that the current model does *not* include a special case; it
simply means the 'private' is resolved at the level of the extension rather
than the level of its members. But that isn't what people expect and it's
not as useful.)

I agree that changing the behavior of *all* access modifiers on
extensions is out of scope. (I also agree that it is a bad idea. Sorry,
James, but wanting 'pubic' here indicates that your mental model of
extensions does not match what Swift is actually doing, and that could get
you into trouble.)

Jordan

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

18

Two weeks ago I had a fairly strong opinion about “private extension” behavior. After following this discussion, I now have no opinion on the matter.

I would summarize the points on both sides as follows:

For the change:
• It is surprising to many people that members of a private extension are implicitly fileprivate.
• There is currently no way to make an extension whose members default to private.

Against the change:
• The proposal is source-breaking.
• The proposal makes “fileprivate” more common.
• A private extension and a (top-level) private type both currently have implicitly fileprivate members. The proposal breaks that symmetry.

Great summary! Thank you.

Notable questions:
• Currently “open” cannot be applied to an extension at all, should we allow it?
• Might we ever want to allow nested (non-top level) extensions, and if so how should access levels on them work?

This could be a solution that would not be source breaking to the topic at hand.

extension MyType {
    private extension {
            // “true” private here
        }
}

I think it would be a good idea to limit the nesting with other extensions. Other idea.

extension { // bag of extensions
    private extension MyType {
            // “true” private here
        }
    fileprivate extension MyType2 {
        // fileprivate here
}
}

I rather have a comprehensive sub module system than nested extensions though. :)

···

On Oct 7, 2017, at 10:17 AM, Nevin Brackett-Rozinsky via swift-evolution <swift-evolution@swift.org> wrote:

Nevin
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

19

Two weeks ago I had a fairly strong opinion about “private extension” behavior. After following this discussion, I now have no opinion on the matter.

I would summarize the points on both sides as follows:

For the change:
• It is surprising to many people that members of a private extension are implicitly fileprivate. > • There is currently no way to make an extension whose members default to private.

I'd add this:
* Current rule for 'private extension' can lead to bugs, when you expect that private methods will be 'true' private but they are fileprivate, so could be called from not-expected code in the same file. Inverse situation(when you need fileprivate but 'private extension' means 'true' private) - can't cause bugs, you'll be notified by the compiler if you need a 'wider' access level.
* The change will make the access-control rule for extensions simpler, not harder to understand.
* 'fileprivate' access level for methods in extension will be used by *intention*, not just because "this is how 'private extension' works". If I understand correctly, it is not the 'fileprivate' *keyword* we want to see less, but the fileprivate *access level*, which should be rare and intentional.

Against the change:
• The proposal is source-breaking.
• The proposal makes “fileprivate” more common.

It depends on what most of Swift developers *mean* when writing 'private extension' - if they actually need 'fileprivate extension' - then yes, we'll see it more in code. But if in most cases the *intention* is to have a bunch of 'true private' methods - we'll have a small number of 'fileprivate extension'.
But in any case, what is the problem with this? If developer *needs* fileprivate access level for methods in extension - this will be clearly stated in code, not hidden under the cute title of 'private extension'

• A private extension and a (top-level) private type both currently have implicitly fileprivate members. The proposal breaks that symmetry.

Is it really good symmetry?
By definition, the rule for applying the access level to type is differ from the rule for extension. Here all symmetry already broken and we have 2 separate rules. And from my point of view, having a symmetry in *this particular* case is a bad thing, it can lead to wrong assumptions. Don't you want to apply the same 'symmetry' rule for the code below ? :

public class C {
     var i = 10
}

public extension C {
     func j(){}
}

,as you understand 'i' is internal, while 'j()' is public. So this could be a dangerous assumption.

Notable questions:
• Currently “open” cannot be applied to an extension at all, should we allow it?

Probably. But this should be a separate pitch/proposal.

• Might we ever want to allow nested (non-top level) extensions, and if so how should access levels on them work?

Not sure if we need them, this is also a subject for separate pitch/proposal.
But if the rule for applying the access level for extension will be as currently(I don't believe we'll change it soon) - nested extensions should work the same "the access level keyword stated before the 'extension' keyword will be virtually copy&pasted to the beginning of each method declaration inside extension and then resolved", IMO this is a most clear rule we can have *in case rule for extensions is differ from rule for type".

Vladimir.

···

On 07.10.2017 20:17, Nevin Brackett-Rozinsky via swift-evolution wrote:

Nevin

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

20

Thanks for hoisting this out into its own thread, Jordan. I was hesitant to
elaborate more on another access level thread :)

I think the change should absolutely be made. Even though the "private"
keyword occurs at the file level, the description of the feature in the
Swift documentation simply states: "you can mark an extension with an
explicit access-level modifier to set a new default access level for all
members defined within the extension." To me, that implies that "private
extension Foo { func bar() }" should be identical to "extension Foo {
private func bar() }", but today it becomes equivalent to "extension Foo {
fileprivate func bar() }".

That seems fundamentally broken, because (1) it's inconsistent, (2)
"private extension" and "fileprivate extension" are two ways of saying the
same thing, non-intuitively, and (3) there's no way for someone to use the
shorthand syntax to take advantage of the new meaning of private within
same-file type extensions.

While I personally never use the shorthand extension access level feature
(because I prefer the explicit form, and because of situations like this
one), I definitely think it should be consistent for people who do want to
use it.

I wonder how much existing code would be affected by this change. Do people
use "private extension" when they really want "fileprivate extension"? I
would hope the number of users affected would be few, at least.

···

On Mon, Oct 2, 2017 at 6:10 PM Jordan Rose via swift-evolution < swift-evolution@swift.org> wrote:

On Oct 2, 2017, at 18:06, Jose Cheyo Jimenez <cheyo@masters3d.com> wrote:

On Oct 2, 2017, at 5:33 PM, Jordan Rose via swift-evolution < > swift-evolution@swift.org> wrote:

On Oct 2, 2017, at 03:25, Vladimir.S via swift-evolution < > swift-evolution@swift.org> wrote:

On 01.10.2017 1:18, Chris Lattner wrote:

On Sep 29, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote:

Vladimir, I agree with you on that change, but it’s a separate topic from
this one.

Tony is absolutely correct that this topic has already been discussed. It
is a deliberate design decision that public types do not automatically
expose members without explicit access modifiers; this has been brought up
on this list, and it is clearly not in scope for discussion as no new
insight can arise this late in the game. The inconsistency with public
extensions was brought up, the proposed solution was to remove modifiers
for extensions, but this proposal was rejected. So, the final design is
what we have.

Agreed. The core team would only consider a refinement or change to
access control if there were something actively broken that mattered for
ABI stability.

So we have to live with *protected* extension inconsistency for very long
time just because core team don't want to even discuss _this particular_
inconsistency(when access level in *private extension* must be private, not
fileprivate)?

Yes, we decided that access level for extension will mean a default and
top most access level for nested methods, OK. But even in this rule, which
already differ from access modifiers for types, we have another one special
case for 'private extension'.

Don't you think this is not normal situation and actually there IMO can't
be any reason to keep this bug-producing inconsistency in Swift?
(especially given Swift 5 seems like is a last moment to fix this)

I hate to say it but I'm inclined to agree with Vladimir on this. "private
extension" has a useful meaning now distinct from "fileprivate extension",
and it was an oversight that SE-0169
<https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md&gt; didn't
include a fix here. On this *very narrow, very specific *access control
issue I think it would still be worth discussing; like Xiaodi said it's not
related to James' original thread-starter.

(I maintain that the current model does *not* include a special case; it
simply means the 'private' is resolved at the level of the extension rather
than the level of its members. But that isn't what people expect and it's
not as useful.)

I agree that changing the behavior of *all* access modifiers on
extensions is out of scope. (I also agree that it is a bad idea. Sorry,
James, but wanting 'pubic' here indicates that your mental model of
extensions does not match what Swift is actually doing, and that could get
you into trouble.)

Jordan

I am not in favor of including a special case for “private extension”
because like Jordan said, private is resolved at the level of the extension
which is always top level currently. A change would make sense if we start
allowing extensions that are not top level. Anything private that is top
level is equivalent to fileprivate so why should “private extension” be any
different?

It's fair to be against this change, but I want to point out that neither
of these are "special cases". Instead it's "access is resolved at the level
of extension and then applied to the member" vs. "access is applied to the
members and then resolved".

Jordan

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution