[swift-evolution] Idea: Public Access Modifier Respected in Type Definition

[Xiaodi Wu]

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 at 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 at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at swift.org>
> >>     https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> >     _______________________________________________
> >     swift-evolution mailing list
> >     swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> >     https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> >
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> _______________________________________________
> 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/20170929/6713329d/attachment.html>