[discussion] final + lazy + fileprivate modifiers

xwu · February 17, 2017, 7:21pm

What you are really asking for is a way of flexibly designating a "unit
of
code" within a module, for which the general solution is submodules. The
objection is that, instead of tackling that issue, these are suggestions
to
invent ad-hoc units of code (scope + extensions only in the same file,
scope + extensions only in the same module, class + extensions only in
the
same file + subclasses only in the same module), and it is possible to
invent arbitrary many of these.

No, sorry, I don't agree with you.
Current situation forces us to generate huge source files or write each
type in its own submodule/file. IMO it is very naturally to have a need to
protect access to some details *even* in the same file(please find David
Sweeris's answer in previous email in this thread. with current 'private'
he can *guarantee* that no code touches internal props even in the same
file), also many of us need a way to share some details only for
extensions/subtypes in other files in the same module/submodule even just
to organize code as *one* need/want and to express intention about who
should "touch" this code and get help from compiler when accidentally try
to use protected method/prop.

I reject the premise that it is a goal of the Swift compiler to protect
you from yourself.

I should clarify, it should certainly protect you from unintentional
accidents that you make, where those are foreseeable, etc. But here we're
talking about _you_ invoking functions that _you_ wrote, which is a pretty
darn clear demonstration of intentionality. And so what I mean to say is
that the Swift compiler, IMO, has no real business trying to protect your
intentions from your other intentions.

You can *guarantee* that nothing in the same file touches what it shouldn't

···

On Fri, Feb 17, 2017 at 1:11 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Fri, Feb 17, 2017 at 12:45 PM, Vladimir.S <svabox@gmail.com> wrote:

On 17.02.2017 20:48, Xiaodi Wu wrote:

touch *by your own eyes*; `private` makes it "easier" but it is by no means
necessary. Indeed I argue that reading code should be the go-to way reason
about the behavior of code, and that compiler help is justified only when
such a method of reasoning is unusually hard or error-prone.

Likewise, you can express intention by documentation. Indeed I argue that
reading the documentation should be the go-to way for a reader to learn how
to use unfamiliar code. Since a user will consult the documentation if he
or she is wondering, "how or when should I use this method?", it is
perfectly sufficient and elegant to put a sentence in the documentation
that says, "actually, you should never use this method." It is self-evident
why one might _want_ compiler help, but it is unclear to me why one _needs_
compiler help for this: after all, if you call an internal method that
doesn't behave as intended, you can read the source code to find out
exactly why--you can even change it!

Someone, who want just internal/public can use only them in own code, no

problems. But many feels that they need a more detailed access levels to
structure their code, they find current situation not comfortable.

As I said, there are arbitrarily many ways to structure your code. If you
insist that the compiler should help you to control, perfectly, exactly
what lines of code can call what other lines of code, and that the way to
spell this desire is through access levels, then you will need many more
access levels. My point is that, taken to its logical end, you would need
infinitely many access levels. Although it would be unnecessary for the
language to active prohibit certain styles of organizing code, I believe
very strongly it is a non-goal of Swift to actively support, by the
addition of new features, all imaginable styles of organizing code.

There is, objectively, an actual minimum number of access modifiers,
which
is two. Those two are: visible only inside the unit of code, or visible
both inside and outside the unit of code. In Swift, those are spelled
internal and public. Everything else here is really talking about better
or
more flexible ways of defining a unit of code.

On Fri, Feb 17, 2017 at 06:21 Vladimir.S via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

    On 17.02.2017 11:29, Slava Pestov via swift-evolution wrote:
    >
    >> On Feb 17, 2017, at 12:09 AM, Charlie Monroe via swift-evolution
    >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>
    <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org
>>>

    wrote:
    >>
    >> True, what I meant was a wider feedback - let's face it, there
are many
    >> more Swift developers now than 2 years ago.
    >>
    >> My objection is not to the documentation itself, but to the fact
    that I'm
    >> unnecessarily exposing an internal implementation detail to the
rest of
    >> the module. Being able to hide it from the rest IMHO leads to
better
    >> though-through API that is indeed meant to be exposed; whereas
exposing
    >> internal details leads to allowing various quick hacks instead.
We know
    >> these quick hacks very well from the ObjC world by accessing
private
    >> parts of the object via duck typing or setting values via KVO.
    >>
    >> At least this is my experience with which the less implementation
    details
    >> are exposed to the outer world, the better.
    >
    > I think the fundamental disagreement we’re seeing in this thread
is the
    > meaning of “outer world”; to some, it means “users of your
module”. To
    > others, it also means “other developers on my team who are working
on
    other
    > files in the module”.
    >
    > Personally I feel enforced encapsulation of implementation detail
to the
    > latter group is less important than the former, and can be handled
by
    > convention. Whereas other users of your module definitely benefit
from
    > access control and being able to consume a clearly-defined
interface.

    I assume we are discussing access modifiers mainly for the former
group,
    i.e. when we are "inside" the module (even when this module is
written by
    the same one person, and especially when it is written by the group).

    "handled by convention" - are we talking about something like
declaring
    props and methods as __privateprop , m_privateprop etc and write
comments
    to mark that they should not be used outside of some scope? Is it
really
    Swifty and acceptable for the modern language? Will this help to
prevent
    some mistakes with incorrect access? Is it better than simple and
clean
    schema for access modifiers and compiler's help? I don't understand
this.

    IMO, access modifiers is very known and handy abstraction to distinct
    levels of access and to structure code many developers knows about
and use
    in other languages.
    At the end, if one wants to keep all internal - no problems!, you
can do
    this right now, just don't use fileprivate/private/etc.

    Yes, I agree we need a simple and clean schema, not
over-complicated, we
    need nice&clean keywords, we need a required minimum of access
modifiers,
    not more, and I do believe currently we don't have this minimum.

    Was already suggested, trying again(I do believe this could be a
    compromised solution to suit needs of the main part of developers):
    * (as currently) public/open -> outside of the module
    * (as currently) internal -> inside module
    * private -> inside file (instead of fileprivate)
    * protected(or *other* keyword) -> inside file + subtype&extensions
in the
    *same module*

    What objections could be made for this?
    Thank you.

    >
    > Slava
    >
    >>
    >>> On Feb 17, 2017, at 8:54 AM, Xiaodi Wu <xiaodi.wu@gmail.com >>> <mailto:xiaodi.wu@gmail.com> >>> >>> <mailto:xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com>>> >>> wrote:
    >>>
    >>> That blog post starts out right away to say that it's a response
to
    >>> community feedback. Moreover, the scenario you describe was just
as
    >>> possible in 2014 as it is now. Finally, then as now, it's
unclear why
    >>> you consider documentation to be "not pretty." After all, your
reader
    >>> would need to consult the documentation before using a variable
anyway.
    >>> On Fri, Feb 17, 2017 at 01:04 Charlie Monroe via swift-evolution >>> >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org >>> >>> >>> wrote:
    >>>
    >>> I'm aware of this, but that's fairly a long time ago -
before Swift
    >>> was open source and had community feedback and before Swift
was
    used
    >>> widely among developers.
    >>>
    >>> To me, real-world use of the language has shown some flaws of
    >>> missing a protected access control, mainly having to decide
between
    >>> having a variable internal or cramming all of the class
extension
    >>> into one file, making it a 3KLOC mess. Either solution is not
    pretty
    >>> - now I have it split among several files with an internal
variable
    >>> commented as "Do not use, for private use of this class
only."
    >>>
    >>>> On Feb 17, 2017, at 7:47 AM, Jose Cheyo Jimenez >>> >>>> <cheyo@masters3d.com <mailto:cheyo@masters3d.com> >>> <mailto:cheyo@masters3d.com <mailto:cheyo@masters3d.com>>> wrote:
    >>>>
    >>>> Access Control and protected - Swift Blog - Apple Developer
    >>>>
    >>>>
    >>>>
    >>>> On Feb 16, 2017, at 10:05 PM, Charlie Monroe via
swift-evolution
    >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.
>
    <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org
>>>
    wrote:
    >>>>
    >>>>> How about removing fileprivate, getting Swift 2 meaning of
    private
    >>>>> (as most people here now suggest) and add additional
@protected
    >>>>> annotation for those who want a more fine-grained solution:
    >>>>>
    >>>>> @protected private - members accessable only from the
    >>>>> class/struct/enum/... and their extensions within the file
    >>>>>
    >>>>> @protected internal - again, but you can access it even
from
    >>>>> extensions and subclasses outside of the file within the
entire
    >>>>> module.
    >>>>>
    >>>>> @protected public/open - the same as above, but outside the
    modules.
    >>>>>
    >>>>> To me, this way most people here will be happy:
    >>>>>
    >>>>> - those wishing the access control gets simplified - it in
fact
    >>>>> does, you don't need to use @protected, if you don't want
    to/need to.
    >>>>> - those who need a fine-grained solution, here it is.
    >>>>>
    >>>>>
    >>>>>
    >>>>>> On Feb 17, 2017, at 3:49 AM, Matthew Johnson via >>> swift-evolution >>> >>>>>> <swift-evolution@swift.org >>> <mailto:swift-evolution@swift.org> <mailto:swift-evolution@swift.org >>> <mailto:swift-evolution@swift.org>>> wrote:
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>> Sent from my iPad
    >>>>>>
    >>>>>>> On Feb 16, 2017, at 8:36 PM, David Sweeris via
swift-evolution
    >>>>>>> <swift-evolution@swift.org
    <mailto:swift-evolution@swift.org> <mailto:swift-evolution@swift.org
    <mailto:swift-evolution@swift.org>>>
    >>>>>>> wrote:
    >>>>>>>
    >>>>>>>
    >>>>>>>> On Feb 16, 2017, at 14:34, Slava Pestov via
swift-evolution
    >>>>>>>> <swift-evolution@swift.org
    <mailto:swift-evolution@swift.org> <mailto:swift-evolution@swift.org
    <mailto:swift-evolution@swift.org>>>
    >>>>>>>> wrote:
    >>>>>>>>
    >>>>>>>> While we’re bikeshedding, I’m going to add my two
cents. Hold
    >>>>>>>> on to your hat because this might be controversial here.
    >>>>>>>>
    >>>>>>>> I think both ‘private’ and ‘fileprivate’ are unnecessary
    >>>>>>>> complications that only serve to clutter the language.
    >>>>>>>>
    >>>>>>>> It would make a lot more sense to just have internal and
    public
    >>>>>>>> only. No private, no fileprivate, no lineprivate, no
    protected.
    >>>>>>>> It’s all silly.
    >>>>>>>
    >>>>>>> Eh, I've used `private` to keep myself honest in terms
of going
    >>>>>>> through some book-keeping functions instead of directly
    >>>>>>> accessing a property.
    >>>>>>
    >>>>>> This is exactly the kind of thing I like it for and why I
    hope we
    >>>>>> might be able to keep scoped access even if it gets a new
name
    >>>>>> that ends up as awkward as fileprivate (allowing private
to
    >>>>>> revert to the Swift 2 meaning).
    >>>>>>
    >>>>>>>
    >>>>>>> - Dave Sweeris
    >>>>>>> _______________________________________________
    >>>>>>> swift-evolution mailing list
    >>>>>>> swift-evolution@swift.org
    <mailto:swift-evolution@swift.org> <mailto: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.
>
    <mailto: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.
>
    <mailto: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>
    <mailto: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>
    <mailto: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 <mailto:swift-evolution@swift.org>
    https://lists.swift.org/mailman/listinfo/swift-evolution

mayoff · February 17, 2017, 11:49pm

Yesterday I stated one intention. Today I (or a coworker) act with a
contradictory intention.

One of these intentions, or some underlying assumption, must be in error.

Why would I want to rely on a human to notice the error, if I can make the
compiler do it?

It is normal to want the compiler to catch my errors. It is strange to
prefer finding errors manually.

You might persuade me that the cost (in language complexity) of having the
compiler detect the contradiction outweighs the benefit.

But I doubt you can persuade me that the detection has no benefit.

···

On Fri, Feb 17, 2017 at 3:56 PM, Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote:

Here, a function call is an _intentional_ act. Writing a function not
meant to be called is an _intentional_ act. It is strange that you would
demand the compiler to stand between two of your own intentional acts.

xwu · February 18, 2017, 12:44am

Here, a function call is an _intentional_ act. Writing a function not
meant to be called is an _intentional_ act. It is strange that you would
demand the compiler to stand between two of your own intentional acts.

Yesterday I stated one intention. Today I (or a coworker) act with a
contradictory intention.

One of these intentions, or some underlying assumption, must be in error.

Must it? Contradiction != error. I can simultaneously not want to expose a
member as the vendor of the API *and* want to invoke the same member as the
consumer of the API. Why must I be in error?

Why would I want to rely on a human to notice the error, if I can make the
compiler do it?

It is normal to want the compiler to catch my errors. It is strange to
prefer finding errors manually.

I can agree that compilers should catch errors. I want to persuade you that
what we are talking about here does not fall into the category of error.

You might persuade me that the cost (in language complexity) of having the

···

On Fri, Feb 17, 2017 at 5:49 PM, Rob Mayoff via swift-evolution < swift-evolution@swift.org> wrote:

On Fri, Feb 17, 2017 at 3:56 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote:
compiler detect the contradiction outweighs the benefit.

But I doubt you can persuade me that the detection has no benefit.

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

Charlie_Monroe1 · February 17, 2017, 9:46pm

What you are really asking for is a way of flexibly designating a "unit of
code" within a module, for which the general solution is submodules. The
objection is that, instead of tackling that issue, these are suggestions to
invent ad-hoc units of code (scope + extensions only in the same file,
scope + extensions only in the same module, class + extensions only in the
same file + subclasses only in the same module), and it is possible to
invent arbitrary many of these.

No, sorry, I don't agree with you.
Current situation forces us to generate huge source files or write each type in its own submodule/file. IMO it is very naturally to have a need to protect access to some details *even* in the same file(please find David Sweeris's answer in previous email in this thread. with current 'private' he can *guarantee* that no code touches internal props even in the same file), also many of us need a way to share some details only for extensions/subtypes in other files in the same module/submodule even just to organize code as *one* need/want and to express intention about who should "touch" this code and get help from compiler when accidentally try to use protected method/prop.

I reject the premise that it is a goal of the Swift compiler to protect you from yourself.

I should clarify, it should certainly protect you from unintentional accidents that you make, where those are foreseeable, etc. But here we're talking about _you_ invoking functions that _you_ wrote, which is a pretty darn clear demonstration of intentionality. And so what I mean to say is that the Swift compiler, IMO, has no real business trying to protect your intentions from your other intentions.

With all due respect (and I do respect you as a person with quite an insight), why does Swift then (by default) check for (U)Int overflows, against nil values, etc, etc. These are all things that are quite protecting you from yourself. In a perfect world, you code your stuff in a way where you don't need these checks as you'd write code that would handle these scenarios. Oh wait, that's Objective-C...

In a similar sense, I believe the compiler/language should prevent you from accidently accessing members that are not designed to be accessed from out of certain scope.

It's not just to protect _you_ from invoking something not being meant to invoke, but others as well.

Documentation is perfect only in a perfect world. I can't count how many times I've come to a project without a single line of comment, not to mention a comment indicating whether the member is meant to be called outside of the file, or if it's marked as internal due to current limitations in access control and it's simply because you needed to split the class amongst several files logic-wise to prevent a bloated single file.

Documentation is not the answer.

···

On Feb 17, 2017, at 8:21 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:
On Fri, Feb 17, 2017 at 1:11 PM, Xiaodi Wu <xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com>> wrote:
On Fri, Feb 17, 2017 at 12:45 PM, Vladimir.S <svabox@gmail.com <mailto:svabox@gmail.com>> wrote:
On 17.02.2017 20:48, Xiaodi Wu wrote:

You can *guarantee* that nothing in the same file touches what it shouldn't touch *by your own eyes*; `private` makes it "easier" but it is by no means necessary. Indeed I argue that reading code should be the go-to way reason about the behavior of code, and that compiler help is justified only when such a method of reasoning is unusually hard or error-prone.

Likewise, you can express intention by documentation. Indeed I argue that reading the documentation should be the go-to way for a reader to learn how to use unfamiliar code. Since a user will consult the documentation if he or she is wondering, "how or when should I use this method?", it is perfectly sufficient and elegant to put a sentence in the documentation that says, "actually, you should never use this method." It is self-evident why one might _want_ compiler help, but it is unclear to me why one _needs_ compiler help for this: after all, if you call an internal method that doesn't behave as intended, you can read the source code to find out exactly why--you can even change it!

Someone, who want just internal/public can use only them in own code, no problems. But many feels that they need a more detailed access levels to structure their code, they find current situation not comfortable.

As I said, there are arbitrarily many ways to structure your code. If you insist that the compiler should help you to control, perfectly, exactly what lines of code can call what other lines of code, and that the way to spell this desire is through access levels, then you will need many more access levels. My point is that, taken to its logical end, you would need infinitely many access levels. Although it would be unnecessary for the language to active prohibit certain styles of organizing code, I believe very strongly it is a non-goal of Swift to actively support, by the addition of new features, all imaginable styles of organizing code.

There is, objectively, an actual minimum number of access modifiers, which
is two. Those two are: visible only inside the unit of code, or visible
both inside and outside the unit of code. In Swift, those are spelled
internal and public. Everything else here is really talking about better or
more flexible ways of defining a unit of code.

On Fri, Feb 17, 2017 at 06:21 Vladimir.S via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>> wrote:

    On 17.02.2017 11:29, Slava Pestov via swift-evolution wrote:
    >
    >> On Feb 17, 2017, at 12:09 AM, Charlie Monroe via swift-evolution > >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>> > <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>>> > > wrote:
    >>
    >> True, what I meant was a wider feedback - let's face it, there are many
    >> more Swift developers now than 2 years ago.
    >>
    >> My objection is not to the documentation itself, but to the fact
    that I'm
    >> unnecessarily exposing an internal implementation detail to the rest of
    >> the module. Being able to hide it from the rest IMHO leads to better
    >> though-through API that is indeed meant to be exposed; whereas exposing
    >> internal details leads to allowing various quick hacks instead. We know
    >> these quick hacks very well from the ObjC world by accessing private
    >> parts of the object via duck typing or setting values via KVO.
    >>
    >> At least this is my experience with which the less implementation
    details
    >> are exposed to the outer world, the better.
    >
    > I think the fundamental disagreement we’re seeing in this thread is the
    > meaning of “outer world”; to some, it means “users of your module”. To
    > others, it also means “other developers on my team who are working on
    other
    > files in the module”.
    >
    > Personally I feel enforced encapsulation of implementation detail to the
    > latter group is less important than the former, and can be handled by
    > convention. Whereas other users of your module definitely benefit from
    > access control and being able to consume a clearly-defined interface.

    I assume we are discussing access modifiers mainly for the former group,
    i.e. when we are "inside" the module (even when this module is written by
    the same one person, and especially when it is written by the group).

    "handled by convention" - are we talking about something like declaring
    props and methods as __privateprop , m_privateprop etc and write comments
    to mark that they should not be used outside of some scope? Is it really
    Swifty and acceptable for the modern language? Will this help to prevent
    some mistakes with incorrect access? Is it better than simple and clean
    schema for access modifiers and compiler's help? I don't understand this.

    IMO, access modifiers is very known and handy abstraction to distinct
    levels of access and to structure code many developers knows about and use
    in other languages.
    At the end, if one wants to keep all internal - no problems!, you can do
    this right now, just don't use fileprivate/private/etc.

    Yes, I agree we need a simple and clean schema, not over-complicated, we
    need nice&clean keywords, we need a required minimum of access modifiers,
    not more, and I do believe currently we don't have this minimum.

    Was already suggested, trying again(I do believe this could be a
    compromised solution to suit needs of the main part of developers):
    * (as currently) public/open -> outside of the module
    * (as currently) internal -> inside module
    * private -> inside file (instead of fileprivate)
    * protected(or *other* keyword) -> inside file + subtype&extensions in the
    *same module*

    What objections could be made for this?
    Thank you.

    >
    > Slava
    >
    >>
    >>> On Feb 17, 2017, at 8:54 AM, Xiaodi Wu <xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com> > <mailto:xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com>> > >>> <mailto:xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com> <mailto:xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com>>>> wrote:
    >>>
    >>> That blog post starts out right away to say that it's a response to
    >>> community feedback. Moreover, the scenario you describe was just as
    >>> possible in 2014 as it is now. Finally, then as now, it's unclear why
    >>> you consider documentation to be "not pretty." After all, your reader
    >>> would need to consult the documentation before using a variable anyway.
    >>> On Fri, Feb 17, 2017 at 01:04 Charlie Monroe via swift-evolution > >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>> > <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>>> > wrote:
    >>>
    >>> I'm aware of this, but that's fairly a long time ago - before Swift
    >>> was open source and had community feedback and before Swift was
    used
    >>> widely among developers.
    >>>
    >>> To me, real-world use of the language has shown some flaws of
    >>> missing a protected access control, mainly having to decide between
    >>> having a variable internal or cramming all of the class extension
    >>> into one file, making it a 3KLOC mess. Either solution is not
    pretty
    >>> - now I have it split among several files with an internal variable
    >>> commented as "Do not use, for private use of this class only."
    >>>
    >>>> On Feb 17, 2017, at 7:47 AM, Jose Cheyo Jimenez > >>>> <cheyo@masters3d.com <mailto:cheyo@masters3d.com> <mailto:cheyo@masters3d.com <mailto:cheyo@masters3d.com>> > <mailto:cheyo@masters3d.com <mailto:cheyo@masters3d.com> <mailto:cheyo@masters3d.com <mailto:cheyo@masters3d.com>>>> wrote:
    >>>>
    >>>> Access Control and protected - Swift Blog - Apple Developer <Access Control and protected - Swift Blog - Apple Developer;
    >>>>
    >>>>
    >>>>
    >>>> On Feb 16, 2017, at 10:05 PM, Charlie Monroe via swift-evolution > >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>> > <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>>> > wrote:
    >>>>
    >>>>> How about removing fileprivate, getting Swift 2 meaning of
    private
    >>>>> (as most people here now suggest) and add additional @protected
    >>>>> annotation for those who want a more fine-grained solution:
    >>>>>
    >>>>> @protected private - members accessable only from the
    >>>>> class/struct/enum/... and their extensions within the file
    >>>>>
    >>>>> @protected internal - again, but you can access it even from
    >>>>> extensions and subclasses outside of the file within the entire
    >>>>> module.
    >>>>>
    >>>>> @protected public/open - the same as above, but outside the
    modules.
    >>>>>
    >>>>> To me, this way most people here will be happy:
    >>>>>
    >>>>> - those wishing the access control gets simplified - it in fact
    >>>>> does, you don't need to use @protected, if you don't want
    to/need to.
    >>>>> - those who need a fine-grained solution, here it is.
    >>>>>
    >>>>>
    >>>>>
    >>>>>> On Feb 17, 2017, at 3:49 AM, Matthew Johnson via swift-evolution > >>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org> > <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org> > <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>>> wrote:
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>> Sent from my iPad
    >>>>>>
    >>>>>>> On Feb 16, 2017, at 8:36 PM, David Sweeris via swift-evolution > >>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org> > <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org> > <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>>> > >>>>>>> wrote:
    >>>>>>>
    >>>>>>>
    >>>>>>>> On Feb 16, 2017, at 14:34, Slava Pestov via swift-evolution > >>>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org> > <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org> > <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>>> > >>>>>>>> wrote:
    >>>>>>>>
    >>>>>>>> While we’re bikeshedding, I’m going to add my two cents. Hold
    >>>>>>>> on to your hat because this might be controversial here.
    >>>>>>>>
    >>>>>>>> I think both ‘private’ and ‘fileprivate’ are unnecessary
    >>>>>>>> complications that only serve to clutter the language.
    >>>>>>>>
    >>>>>>>> It would make a lot more sense to just have internal and
    public
    >>>>>>>> only. No private, no fileprivate, no lineprivate, no
    protected.
    >>>>>>>> It’s all silly.
    >>>>>>>
    >>>>>>> Eh, I've used `private` to keep myself honest in terms of going
    >>>>>>> through some book-keeping functions instead of directly
    >>>>>>> accessing a property.
    >>>>>>
    >>>>>> This is exactly the kind of thing I like it for and why I
    hope we
    >>>>>> might be able to keep scoped access even if it gets a new name
    >>>>>> that ends up as awkward as fileprivate (allowing private to
    >>>>>> revert to the Swift 2 meaning).
    >>>>>>
    >>>>>>>
    >>>>>>> - Dave Sweeris
    >>>>>>> _______________________________________________
    >>>>>>> swift-evolution mailing list
    >>>>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
    <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>
    <mailto: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> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>
    <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto: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> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>
    <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto: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> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>
    <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto: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> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>
    <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto: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> <mailto: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> <mailto: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

Charlie_Monroe1 · February 18, 2017, 2:31pm

What you are really asking for is a way of flexibly designating a "unit of
code" within a module, for which the general solution is submodules. The
objection is that, instead of tackling that issue, these are suggestions to
invent ad-hoc units of code (scope + extensions only in the same file,
scope + extensions only in the same module, class + extensions only in the
same file + subclasses only in the same module), and it is possible to
invent arbitrary many of these.

No, sorry, I don't agree with you.
Current situation forces us to generate huge source files or write each type in its own submodule/file. IMO it is very naturally to have a need to protect access to some details *even* in the same file(please find David Sweeris's answer in previous email in this thread. with current 'private' he can *guarantee* that no code touches internal props even in the same file), also many of us need a way to share some details only for extensions/subtypes in other files in the same module/submodule even just to organize code as *one* need/want and to express intention about who should "touch" this code and get help from compiler when accidentally try to use protected method/prop.

I reject the premise that it is a goal of the Swift compiler to protect you from yourself.

I should clarify, it should certainly protect you from unintentional accidents that you make, where those are foreseeable, etc. But here we're talking about _you_ invoking functions that _you_ wrote, which is a pretty darn clear demonstration of intentionality. And so what I mean to say is that the Swift compiler, IMO, has no real business trying to protect your intentions from your other intentions.

With all due respect (and I do respect you as a person with quite an insight), why does Swift then (by default) check for (U)Int overflows, against nil values, etc, etc. These are all things that are quite protecting you from yourself. In a perfect world, you code your stuff in a way where you don't need these checks as you'd write code that would handle these scenarios. Oh wait, that's Objective-C...

Overflow, nil values, etc., all go to Swift's promising of memory safety by default. They also reflect errors of omission: we unintentionally forget to handle these cases. Here, a function call is an _intentional_ act. Writing a function not meant to be called is an _intentional_ act. It is strange that you would demand the compiler to stand between two of your own intentional acts.

It's not that it's not meant to be called, but to be called from certain context. Coming back to a codebase after a while, you don't need to remember that method is not meant to be called out of certain context and if you name your methods well, you don't really need to go and take a look at what the method does, so you might miss this fact since you didn't go and read the docs. Xcode wouldn't even offer you this method in autocompletion if it were marked protected.

I'm not saying that this is something the Swift community can't live without, but it's of a huge convenience for newcomers to a project for whom the IDE wouldn't offer methods that should not get called from outside of the enclosing type.

I believe we are running to a point where the community is divided into two major camps - one part that would like to get the access control almost eliminated as they don't the see it that much useful; and second part that on the other hand would very much like to see extended access control - not by files/modules, but by the enclosing type. People are unlikely to switch these camps as their view on the subject is mostly shaped by their previous experience with working on team projects.

IMHO, those who have previously worked with other experienced and responsible developers are probably advocates of less access control; those who have previously worked will less experienced developers are most likely pushing forward a more extended access control model.

I've previously worked as a lead developer in a few start-up businesses where people came and went and it was unnecessary burden to point to them why they shouldn't do something that way, that they overlooked that the member should not be invoked out of the enclosing context because they didn't full read documentation for that method; when you do this with a 10th person for the 100th time, you start wondering if this is one of those things that the language should help with a little by providing means of preventing people of misusing/abusing certain parts of the API.

···

On Feb 17, 2017, at 10:56 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
On Fri, Feb 17, 2017 at 3:46 PM, Charlie Monroe <charlie@charliemonroe.net <mailto:charlie@charliemonroe.net>> wrote:

On Feb 17, 2017, at 8:21 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Fri, Feb 17, 2017 at 1:11 PM, Xiaodi Wu <xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com>> wrote:
On Fri, Feb 17, 2017 at 12:45 PM, Vladimir.S <svabox@gmail.com <mailto:svabox@gmail.com>> wrote:
On 17.02.2017 20:48, Xiaodi Wu wrote:

In a similar sense, I believe the compiler/language should prevent you from accidently accessing members that are not designed to be accessed from out of certain scope.

It's not just to protect _you_ from invoking something not being meant to invoke, but others as well.

Others that are part of the collective "you" working on the project, the group of people who have permissions to touch the source code.

Documentation is perfect only in a perfect world. I can't count how many times I've come to a project without a single line of comment, not to mention a comment indicating whether the member is meant to be called outside of the file, or if it's marked as internal due to current limitations in access control and it's simply because you needed to split the class amongst several files logic-wise to prevent a bloated single file.

Documentation is not the answer.

If documentation is not the answer, then by that line of reasoning, neither is access control. An author who can't be bothered to document that something shouldn't be used won't be bothered to determine what an appropriate access modifier would be, either. My point is that additional access modifiers don't help you express yourself any more than documentation does. Put another way, the access modifiers you advocate for are simply an alternative spelling for a comment.

You can *guarantee* that nothing in the same file touches what it shouldn't touch *by your own eyes*; `private` makes it "easier" but it is by no means necessary. Indeed I argue that reading code should be the go-to way reason about the behavior of code, and that compiler help is justified only when such a method of reasoning is unusually hard or error-prone.

Likewise, you can express intention by documentation. Indeed I argue that reading the documentation should be the go-to way for a reader to learn how to use unfamiliar code. Since a user will consult the documentation if he or she is wondering, "how or when should I use this method?", it is perfectly sufficient and elegant to put a sentence in the documentation that says, "actually, you should never use this method." It is self-evident why one might _want_ compiler help, but it is unclear to me why one _needs_ compiler help for this: after all, if you call an internal method that doesn't behave as intended, you can read the source code to find out exactly why--you can even change it!

Someone, who want just internal/public can use only them in own code, no problems. But many feels that they need a more detailed access levels to structure their code, they find current situation not comfortable.

As I said, there are arbitrarily many ways to structure your code. If you insist that the compiler should help you to control, perfectly, exactly what lines of code can call what other lines of code, and that the way to spell this desire is through access levels, then you will need many more access levels. My point is that, taken to its logical end, you would need infinitely many access levels. Although it would be unnecessary for the language to active prohibit certain styles of organizing code, I believe very strongly it is a non-goal of Swift to actively support, by the addition of new features, all imaginable styles of organizing code.

There is, objectively, an actual minimum number of access modifiers, which
is two. Those two are: visible only inside the unit of code, or visible
both inside and outside the unit of code. In Swift, those are spelled
internal and public. Everything else here is really talking about better or
more flexible ways of defining a unit of code.

On Fri, Feb 17, 2017 at 06:21 Vladimir.S via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>> wrote:

    On 17.02.2017 11:29, Slava Pestov via swift-evolution wrote:
    >
    >> On Feb 17, 2017, at 12:09 AM, Charlie Monroe via swift-evolution >> >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>> >> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>>> >> >> wrote:
    >>
    >> True, what I meant was a wider feedback - let's face it, there are many
    >> more Swift developers now than 2 years ago.
    >>
    >> My objection is not to the documentation itself, but to the fact
    that I'm
    >> unnecessarily exposing an internal implementation detail to the rest of
    >> the module. Being able to hide it from the rest IMHO leads to better
    >> though-through API that is indeed meant to be exposed; whereas exposing
    >> internal details leads to allowing various quick hacks instead. We know
    >> these quick hacks very well from the ObjC world by accessing private
    >> parts of the object via duck typing or setting values via KVO.
    >>
    >> At least this is my experience with which the less implementation
    details
    >> are exposed to the outer world, the better.
    >
    > I think the fundamental disagreement we’re seeing in this thread is the
    > meaning of “outer world”; to some, it means “users of your module”. To
    > others, it also means “other developers on my team who are working on
    other
    > files in the module”.
    >
    > Personally I feel enforced encapsulation of implementation detail to the
    > latter group is less important than the former, and can be handled by
    > convention. Whereas other users of your module definitely benefit from
    > access control and being able to consume a clearly-defined interface.

    I assume we are discussing access modifiers mainly for the former group,
    i.e. when we are "inside" the module (even when this module is written by
    the same one person, and especially when it is written by the group).

    "handled by convention" - are we talking about something like declaring
    props and methods as __privateprop , m_privateprop etc and write comments
    to mark that they should not be used outside of some scope? Is it really
    Swifty and acceptable for the modern language? Will this help to prevent
    some mistakes with incorrect access? Is it better than simple and clean
    schema for access modifiers and compiler's help? I don't understand this.

    IMO, access modifiers is very known and handy abstraction to distinct
    levels of access and to structure code many developers knows about and use
    in other languages.
    At the end, if one wants to keep all internal - no problems!, you can do
    this right now, just don't use fileprivate/private/etc.

    Yes, I agree we need a simple and clean schema, not over-complicated, we
    need nice&clean keywords, we need a required minimum of access modifiers,
    not more, and I do believe currently we don't have this minimum.

    Was already suggested, trying again(I do believe this could be a
    compromised solution to suit needs of the main part of developers):
    * (as currently) public/open -> outside of the module
    * (as currently) internal -> inside module
    * private -> inside file (instead of fileprivate)
    * protected(or *other* keyword) -> inside file + subtype&extensions in the
    *same module*

    What objections could be made for this?
    Thank you.

    >
    > Slava
    >
    >>
    >>> On Feb 17, 2017, at 8:54 AM, Xiaodi Wu <xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com> >> <mailto:xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com>> >> >>> <mailto:xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com> <mailto:xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com>>>> wrote:
    >>>
    >>> That blog post starts out right away to say that it's a response to
    >>> community feedback. Moreover, the scenario you describe was just as
    >>> possible in 2014 as it is now. Finally, then as now, it's unclear why
    >>> you consider documentation to be "not pretty." After all, your reader
    >>> would need to consult the documentation before using a variable anyway.
    >>> On Fri, Feb 17, 2017 at 01:04 Charlie Monroe via swift-evolution >> >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>> >> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>>> >> wrote:
    >>>
    >>> I'm aware of this, but that's fairly a long time ago - before Swift
    >>> was open source and had community feedback and before Swift was
    used
    >>> widely among developers.
    >>>
    >>> To me, real-world use of the language has shown some flaws of
    >>> missing a protected access control, mainly having to decide between
    >>> having a variable internal or cramming all of the class extension
    >>> into one file, making it a 3KLOC mess. Either solution is not
    pretty
    >>> - now I have it split among several files with an internal variable
    >>> commented as "Do not use, for private use of this class only."
    >>>
    >>>> On Feb 17, 2017, at 7:47 AM, Jose Cheyo Jimenez >> >>>> <cheyo@masters3d.com <mailto:cheyo@masters3d.com> <mailto:cheyo@masters3d.com <mailto:cheyo@masters3d.com>> >> <mailto:cheyo@masters3d.com <mailto:cheyo@masters3d.com> <mailto:cheyo@masters3d.com <mailto:cheyo@masters3d.com>>>> wrote:
    >>>>
    >>>> Access Control and protected - Swift Blog - Apple Developer <Access Control and protected - Swift Blog - Apple Developer;
    >>>>
    >>>>
    >>>>
    >>>> On Feb 16, 2017, at 10:05 PM, Charlie Monroe via swift-evolution >> >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>> >> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>>> >> wrote:
    >>>>
    >>>>> How about removing fileprivate, getting Swift 2 meaning of
    private
    >>>>> (as most people here now suggest) and add additional @protected
    >>>>> annotation for those who want a more fine-grained solution:
    >>>>>
    >>>>> @protected private - members accessable only from the
    >>>>> class/struct/enum/... and their extensions within the file
    >>>>>
    >>>>> @protected internal - again, but you can access it even from
    >>>>> extensions and subclasses outside of the file within the entire
    >>>>> module.
    >>>>>
    >>>>> @protected public/open - the same as above, but outside the
    modules.
    >>>>>
    >>>>> To me, this way most people here will be happy:
    >>>>>
    >>>>> - those wishing the access control gets simplified - it in fact
    >>>>> does, you don't need to use @protected, if you don't want
    to/need to.
    >>>>> - those who need a fine-grained solution, here it is.
    >>>>>
    >>>>>
    >>>>>
    >>>>>> On Feb 17, 2017, at 3:49 AM, Matthew Johnson via swift-evolution >> >>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>>> wrote:
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>> Sent from my iPad
    >>>>>>
    >>>>>>> On Feb 16, 2017, at 8:36 PM, David Sweeris via swift-evolution >> >>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>>> >> >>>>>>> wrote:
    >>>>>>>
    >>>>>>>
    >>>>>>>> On Feb 16, 2017, at 14:34, Slava Pestov via swift-evolution >> >>>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>>> >> >>>>>>>> wrote:
    >>>>>>>>
    >>>>>>>> While we’re bikeshedding, I’m going to add my two cents. Hold
    >>>>>>>> on to your hat because this might be controversial here.
    >>>>>>>>
    >>>>>>>> I think both ‘private’ and ‘fileprivate’ are unnecessary
    >>>>>>>> complications that only serve to clutter the language.
    >>>>>>>>
    >>>>>>>> It would make a lot more sense to just have internal and
    public
    >>>>>>>> only. No private, no fileprivate, no lineprivate, no
    protected.
    >>>>>>>> It’s all silly.
    >>>>>>>
    >>>>>>> Eh, I've used `private` to keep myself honest in terms of going
    >>>>>>> through some book-keeping functions instead of directly
    >>>>>>> accessing a property.
    >>>>>>
    >>>>>> This is exactly the kind of thing I like it for and why I
    hope we
    >>>>>> might be able to keep scoped access even if it gets a new name
    >>>>>> that ends up as awkward as fileprivate (allowing private to
    >>>>>> revert to the Swift 2 meaning).
    >>>>>>
    >>>>>>>
    >>>>>>> - Dave Sweeris
    >>>>>>> _______________________________________________
    >>>>>>> swift-evolution mailing list
    >>>>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
    <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>
    <mailto: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> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>
    <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto: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> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>
    <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto: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> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>
    <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto: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> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>
    <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto: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> <mailto: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> <mailto: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

Panajev · February 19, 2017, 9:20am

Coming from any other modern language has a much harsher friend in default methods in protocol extensions and having code execution once again depend on the reference type in those cases and no protection to tell you that your code is at risk of this occurring (your class method only called if you use the class type to reference the created instance).

The current private is closer to other languages than the previous one we had which now has in fileprivate a better name.

···

Sent from my iPhone

On 19 Feb 2017, at 08:12, Rien via swift-evolution <swift-evolution@swift.org> wrote:

A parabel: Nobody is going to invest a week of his time so save $1 of taxes per year. Yet somebody who receives those millions of dollars will invest -if need be- all of his time to keep it coming. Guess who wins?

Same with private. There is no BIG harm. But a great many of very little minor ones. Learning swift, increased cognitive load during programming, mistakes to be corrected, difficulty in testing, and I am sure many more can be found.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: Balancingrock (Rien) · GitHub
Project: http://swiftfire.nl

On 19 Feb 2017, at 07:57, Jose Cheyo Jimenez via swift-evolution <swift-evolution@swift.org> wrote:

How exactly is the use of scope private harmful?

Do you have specific examples when scope private was harmful?

On Feb 18, 2017, at 9:06 PM, Zach Waldowski via swift-evolution <swift-evolution@swift.org> wrote:

On Fri, Feb 17, 2017, at 07:52 PM, Jose Cheyo Jimenez via swift-evolution wrote:

I don’t think there is evidence that scope private in Swift3 is "actively harmful”.

This thread would quite simply not exist if not to present exactly that evidence. It exists; we, the change's detractors, exist.

Zachary

_______________________________________________
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

masters3d · February 20, 2017, 5:46am

Swift 2’s access modifiers had a very simple ‘elevator pitch’ -
“If you are writing code, by default everything within the module (app or library) your are working in can see it, but other modules cannot. If you want other modules to see features of your module, you make them public. If something is an implementation detail that even other parts of your module shouldn’t mess with, you make them private”

I think I would have trouble *just* describing private vs file private in that amount of space. One sign of the complexity was that even after a ridiculous amount of bike shedding, we couldn’t come up with better way to distinguish the two than to call one “fileprivate”. So I would say for the purposes of swift as a language suitable for learning, the change was harmful.

Swift’s scope private is not different than other languages.

Secondly, there are reasons to choose one versus the other, but the combination of the meaning of the keyword changing between swift 2 and 3 and the spelling of “fileprivate” means that the choice of one or the other doesn’t really communicate anything to a developer of a typical project - it appears to often be a matter of the legacy of the code as well as developer taste. That the choice between private and file private doesn’t illustrate intent is harmful to coordination.

This really depends on where private is. If it on the top scope then private is the same as file-private and your statement is correct.

SE-0025 was changed to allow higher access modifier for inner types and this is when things started to get confusing because the vast majority of times when scope private was being used in reality is the same as fileprivate. The fact that we encourage the use of scope private over file-private is harmful because of the confusion.

// File.swift

private let myString = "" // fileprivate same as private
fileprivate let myString2 = "" // fileprivate same as private

private struct MyType { // fileprivate same as private
    fileprivate struct MyInnerType{ // private never the same as private
        fileprivate struct MyInnerType{} // private never the same as private
    }
}

// end of File.swift

···

On Feb 19, 2017, at 7:29 PM, David Waite <david@alkaline-solutions.com> wrote:

A third point (which is a bit more complex/convoluted) is that fileprivate remained an essential language feature because it allows implementation in extensions, and allows a simple “friend”-like feature where types that need access to implementation details due to higher coupling could be bundled into the same file. Outside of a desire of a scoped ‘private’ simply to match the behavior of certain other languages, private is used to hide implementation details from other parts of a file, while file private exposes them within the file.

There is a potential that file-private can lead to an explosion of complexity due to a large amount of “friendly types” being bundled into the same file. In that sense, ‘private’ was wrong because it was adding complexity at the file level, when really a new access level would possibly have been more productive to define at the at the small-group-of-files level - either via a friend access level or submodules. We still have the potential of unmanageable files due to friend types, but any additional access levels to aid with this problem would have to be weighed against a now significantly more complex access model including file and scoped private. In that sense, the inclusion of scoped private may indeed be harmful in that it increases the challenge of much more useful access levels being added to the language.

-DW

On Feb 18, 2017, at 11:57 PM, Jose Cheyo Jimenez via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

How exactly is the use of scope private harmful?

Do you have specific examples when scope private was harmful?

On Feb 18, 2017, at 9:06 PM, Zach Waldowski via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Fri, Feb 17, 2017, at 07:52 PM, Jose Cheyo Jimenez via swift-evolution wrote:

I don’t think there is evidence that scope private in Swift3 is "actively harmful”.

This thread would quite simply not exist if not to present exactly that evidence. It exists; we, the change's detractors, exist.

Zachary

_______________________________________________
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

Jon_Hull · February 20, 2017, 8:30am

This is the core of what I have been saying. If we don’t address this need of “friendly types” in a swift-y way, we will have to keep coming back to the drawing board (either for “friend” or “protected” or “submodules”). I really like swift 2 private, but it did cause long files because all of the extensions and friends had to be stuck in the same file. What we are really missing is something that has the connotation similar to private, but allows access where needed.

I agree with most of what was said in this blog post from the swift devs:

The main exception is that I disagree that ‘internal’ maps to the ObjC case where a second header was used (it doesn’t, and that is what is causing all of this trouble). Because internal is the default, it feels much too easy to accidentally use parts of a type which should only be used by extensions/subclasses/friend types. Remember, in an app (as opposed to a framework), internal is basically equivalent to public. With the second header, users of the contents of that header had to explicitly include it, which meant there was no chance of accidental use.

What we need is something which maps to that second header case while still keeping everything conceptually simple and swift-y.

Thanks,
Jon

···

On Feb 19, 2017, at 7:29 PM, David Waite via swift-evolution <swift-evolution@swift.org> wrote:

A third point (which is a bit more complex/convoluted) is that fileprivate remained an essential language feature because it allows implementation in extensions, and allows a simple “friend”-like feature where types that need access to implementation details due to higher coupling could be bundled into the same file. Outside of a desire of a scoped ‘private’ simply to match the behavior of certain other languages, private is used to hide implementation details from other parts of a file, while file private exposes them within the file.

There is a potential that file-private can lead to an explosion of complexity due to a large amount of “friendly types” being bundled into the same file. In that sense, ‘private’ was wrong because it was adding complexity at the file level, when really a new access level would possibly have been more productive to define at the at the small-group-of-files level - either via a friend access level or submodules. We still have the potential of unmanageable files due to friend types, but any additional access levels to aid with this problem would have to be weighed against a now significantly more complex access model including file and scoped private. In that sense, the inclusion of scoped private may indeed be harmful in that it increases the challenge of much more useful access levels being added to the language.

xwu · February 17, 2017, 9:56pm

What you are really asking for is a way of flexibly designating a "unit
of
code" within a module, for which the general solution is submodules. The
objection is that, instead of tackling that issue, these are
suggestions to
invent ad-hoc units of code (scope + extensions only in the same file,
scope + extensions only in the same module, class + extensions only in
the
same file + subclasses only in the same module), and it is possible to
invent arbitrary many of these.

No, sorry, I don't agree with you.
Current situation forces us to generate huge source files or write each
type in its own submodule/file. IMO it is very naturally to have a need to
protect access to some details *even* in the same file(please find David
Sweeris's answer in previous email in this thread. with current 'private'
he can *guarantee* that no code touches internal props even in the same
file), also many of us need a way to share some details only for
extensions/subtypes in other files in the same module/submodule even just
to organize code as *one* need/want and to express intention about who
should "touch" this code and get help from compiler when accidentally try
to use protected method/prop.

I reject the premise that it is a goal of the Swift compiler to protect
you from yourself.

I should clarify, it should certainly protect you from unintentional
accidents that you make, where those are foreseeable, etc. But here we're
talking about _you_ invoking functions that _you_ wrote, which is a pretty
darn clear demonstration of intentionality. And so what I mean to say is
that the Swift compiler, IMO, has no real business trying to protect your
intentions from your other intentions.

With all due respect (and I do respect you as a person with quite an
insight), why does Swift then (by default) check for (U)Int overflows,
against nil values, etc, etc. These are all things that are quite
protecting you from yourself. In a perfect world, you code your stuff in a
way where you don't need these checks as you'd write code that would handle
these scenarios. Oh wait, that's Objective-C...

Overflow, nil values, etc., all go to Swift's promising of memory safety by
default. They also reflect errors of omission: we unintentionally forget to
handle these cases. Here, a function call is an _intentional_ act. Writing
a function not meant to be called is an _intentional_ act. It is strange
that you would demand the compiler to stand between two of your own
intentional acts.

In a similar sense, I believe the compiler/language should prevent you
from accidently accessing members that are not designed to be accessed from
out of certain scope.

It's not just to protect _you_ from invoking something not being meant to
invoke, but others as well.

Others that are part of the collective "you" working on the project, the
group of people who have permissions to touch the source code.

Documentation is perfect only in a perfect world. I can't count how many
times I've come to a project without a single line of comment, not to
mention a comment indicating whether the member is meant to be called
outside of the file, or if it's marked as internal due to current
limitations in access control and it's simply because you needed to split
the class amongst several files logic-wise to prevent a bloated single file.

Documentation is not the answer.

If documentation is not the answer, then by that line of reasoning, neither
is access control. An author who can't be bothered to document that
something shouldn't be used won't be bothered to determine what an
appropriate access modifier would be, either. My point is that additional
access modifiers don't help you express yourself any more than
documentation does. Put another way, the access modifiers you advocate for
are simply an alternative spelling for a comment.

You can *guarantee* that nothing in the same file touches what it shouldn't

···

On Fri, Feb 17, 2017 at 3:46 PM, Charlie Monroe <charlie@charliemonroe.net> wrote:

On Feb 17, 2017, at 8:21 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote:
On Fri, Feb 17, 2017 at 1:11 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Fri, Feb 17, 2017 at 12:45 PM, Vladimir.S <svabox@gmail.com> wrote:

On 17.02.2017 20:48, Xiaodi Wu wrote:

touch *by your own eyes*; `private` makes it "easier" but it is by no means
necessary. Indeed I argue that reading code should be the go-to way reason
about the behavior of code, and that compiler help is justified only when
such a method of reasoning is unusually hard or error-prone.

Likewise, you can express intention by documentation. Indeed I argue that
reading the documentation should be the go-to way for a reader to learn how
to use unfamiliar code. Since a user will consult the documentation if he
or she is wondering, "how or when should I use this method?", it is
perfectly sufficient and elegant to put a sentence in the documentation
that says, "actually, you should never use this method." It is self-evident
why one might _want_ compiler help, but it is unclear to me why one _needs_
compiler help for this: after all, if you call an internal method that
doesn't behave as intended, you can read the source code to find out
exactly why--you can even change it!

Someone, who want just internal/public can use only them in own code, no

problems. But many feels that they need a more detailed access levels to
structure their code, they find current situation not comfortable.

As I said, there are arbitrarily many ways to structure your code. If you
insist that the compiler should help you to control, perfectly, exactly
what lines of code can call what other lines of code, and that the way to
spell this desire is through access levels, then you will need many more
access levels. My point is that, taken to its logical end, you would need
infinitely many access levels. Although it would be unnecessary for the
language to active prohibit certain styles of organizing code, I believe
very strongly it is a non-goal of Swift to actively support, by the
addition of new features, all imaginable styles of organizing code.

There is, objectively, an actual minimum number of access modifiers,
which
is two. Those two are: visible only inside the unit of code, or visible
both inside and outside the unit of code. In Swift, those are spelled
internal and public. Everything else here is really talking about
better or
more flexible ways of defining a unit of code.

On Fri, Feb 17, 2017 at 06:21 Vladimir.S via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

    On 17.02.2017 11:29, Slava Pestov via swift-evolution wrote:
    >
    >> On Feb 17, 2017, at 12:09 AM, Charlie Monroe via swift-evolution
    >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>
    <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org
>>>

    wrote:
    >>
    >> True, what I meant was a wider feedback - let's face it, there
are many
    >> more Swift developers now than 2 years ago.
    >>
    >> My objection is not to the documentation itself, but to the fact
    that I'm
    >> unnecessarily exposing an internal implementation detail to the
rest of
    >> the module. Being able to hide it from the rest IMHO leads to
better
    >> though-through API that is indeed meant to be exposed; whereas
exposing
    >> internal details leads to allowing various quick hacks instead.
We know
    >> these quick hacks very well from the ObjC world by accessing
private
    >> parts of the object via duck typing or setting values via KVO.
    >>
    >> At least this is my experience with which the less
implementation
    details
    >> are exposed to the outer world, the better.
    >
    > I think the fundamental disagreement we’re seeing in this thread
is the
    > meaning of “outer world”; to some, it means “users of your
module”. To
    > others, it also means “other developers on my team who are
working on
    other
    > files in the module”.
    >
    > Personally I feel enforced encapsulation of implementation
detail to the
    > latter group is less important than the former, and can be
handled by
    > convention. Whereas other users of your module definitely
benefit from
    > access control and being able to consume a clearly-defined
interface.

    I assume we are discussing access modifiers mainly for the former
group,
    i.e. when we are "inside" the module (even when this module is
written by
    the same one person, and especially when it is written by the
group).

    "handled by convention" - are we talking about something like
declaring
    props and methods as __privateprop , m_privateprop etc and write
comments
    to mark that they should not be used outside of some scope? Is it
really
    Swifty and acceptable for the modern language? Will this help to
prevent
    some mistakes with incorrect access? Is it better than simple and
clean
    schema for access modifiers and compiler's help? I don't
understand this.

    IMO, access modifiers is very known and handy abstraction to
distinct
    levels of access and to structure code many developers knows about
and use
    in other languages.
    At the end, if one wants to keep all internal - no problems!, you
can do
    this right now, just don't use fileprivate/private/etc.

    Yes, I agree we need a simple and clean schema, not
over-complicated, we
    need nice&clean keywords, we need a required minimum of access
modifiers,
    not more, and I do believe currently we don't have this minimum.

    Was already suggested, trying again(I do believe this could be a
    compromised solution to suit needs of the main part of developers):
    * (as currently) public/open -> outside of the module
    * (as currently) internal -> inside module
    * private -> inside file (instead of fileprivate)
    * protected(or *other* keyword) -> inside file +
subtype&extensions in the
    *same module*

    What objections could be made for this?
    Thank you.

    >
    > Slava
    >
    >>
    >>> On Feb 17, 2017, at 8:54 AM, Xiaodi Wu <xiaodi.wu@gmail.com >>>> <mailto:xiaodi.wu@gmail.com> >>>> >>> <mailto:xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com>>> >>>> wrote:
    >>>
    >>> That blog post starts out right away to say that it's a
response to
    >>> community feedback. Moreover, the scenario you describe was
just as
    >>> possible in 2014 as it is now. Finally, then as now, it's
unclear why
    >>> you consider documentation to be "not pretty." After all, your
reader
    >>> would need to consult the documentation before using a
variable anyway.
    >>> On Fri, Feb 17, 2017 at 01:04 Charlie Monroe via
swift-evolution
    >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>
    <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org
>>>
    wrote:
    >>>
    >>> I'm aware of this, but that's fairly a long time ago -
before Swift
    >>> was open source and had community feedback and before
Swift was
    used
    >>> widely among developers.
    >>>
    >>> To me, real-world use of the language has shown some flaws
of
    >>> missing a protected access control, mainly having to
decide between
    >>> having a variable internal or cramming all of the class
extension
    >>> into one file, making it a 3KLOC mess. Either solution is
not
    pretty
    >>> - now I have it split among several files with an internal
variable
    >>> commented as "Do not use, for private use of this class
only."
    >>>
    >>>> On Feb 17, 2017, at 7:47 AM, Jose Cheyo Jimenez >>>> >>>> <cheyo@masters3d.com <mailto:cheyo@masters3d.com> >>>> <mailto:cheyo@masters3d.com <mailto:cheyo@masters3d.com>>> wrote:
    >>>>
    >>>> Access Control and protected - Swift Blog - Apple Developer
    >>>>
    >>>>
    >>>>
    >>>> On Feb 16, 2017, at 10:05 PM, Charlie Monroe via
swift-evolution
    >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.o
>
    <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org
>>>
    wrote:
    >>>>
    >>>>> How about removing fileprivate, getting Swift 2 meaning
of
    private
    >>>>> (as most people here now suggest) and add additional
@protected
    >>>>> annotation for those who want a more fine-grained
solution:
    >>>>>
    >>>>> @protected private - members accessable only from the
    >>>>> class/struct/enum/... and their extensions within the
file
    >>>>>
    >>>>> @protected internal - again, but you can access it even
from
    >>>>> extensions and subclasses outside of the file within the
entire
    >>>>> module.
    >>>>>
    >>>>> @protected public/open - the same as above, but outside
the
    modules.
    >>>>>
    >>>>> To me, this way most people here will be happy:
    >>>>>
    >>>>> - those wishing the access control gets simplified - it
in fact
    >>>>> does, you don't need to use @protected, if you don't want
    to/need to.
    >>>>> - those who need a fine-grained solution, here it is.
    >>>>>
    >>>>>
    >>>>>
    >>>>>> On Feb 17, 2017, at 3:49 AM, Matthew Johnson via
swift-evolution
    >>>>>> <swift-evolution@swift.org
    <mailto:swift-evolution@swift.org> <mailto:swift-evolution@swift.
org
    <mailto:swift-evolution@swift.org>>> wrote:
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>> Sent from my iPad
    >>>>>>
    >>>>>>> On Feb 16, 2017, at 8:36 PM, David Sweeris via
swift-evolution
    >>>>>>> <swift-evolution@swift.org
    <mailto:swift-evolution@swift.org> <mailto:swift-evolution@swift.
org
    <mailto:swift-evolution@swift.org>>>
    >>>>>>> wrote:
    >>>>>>>
    >>>>>>>
    >>>>>>>> On Feb 16, 2017, at 14:34, Slava Pestov via
swift-evolution
    >>>>>>>> <swift-evolution@swift.org
    <mailto:swift-evolution@swift.org> <mailto:swift-evolution@swift.
org
    <mailto:swift-evolution@swift.org>>>
    >>>>>>>> wrote:
    >>>>>>>>
    >>>>>>>> While we’re bikeshedding, I’m going to add my two
cents. Hold
    >>>>>>>> on to your hat because this might be controversial
here.
    >>>>>>>>
    >>>>>>>> I think both ‘private’ and ‘fileprivate’ are
unnecessary
    >>>>>>>> complications that only serve to clutter the language.
    >>>>>>>>
    >>>>>>>> It would make a lot more sense to just have internal
and
    public
    >>>>>>>> only. No private, no fileprivate, no lineprivate, no
    protected.
    >>>>>>>> It’s all silly.
    >>>>>>>
    >>>>>>> Eh, I've used `private` to keep myself honest in terms
of going
    >>>>>>> through some book-keeping functions instead of directly
    >>>>>>> accessing a property.
    >>>>>>
    >>>>>> This is exactly the kind of thing I like it for and why
I
    hope we
    >>>>>> might be able to keep scoped access even if it gets a
new name
    >>>>>> that ends up as awkward as fileprivate (allowing
private to
    >>>>>> revert to the Swift 2 meaning).
    >>>>>>
    >>>>>>>
    >>>>>>> - Dave Sweeris
    >>>>>>> _______________________________________________
    >>>>>>> swift-evolution mailing list
    >>>>>>> swift-evolution@swift.org
    <mailto:swift-evolution@swift.org> <mailto:swift-evolution@swift.
org
    <mailto:swift-evolution@swift.org>>
    >>>>>>> https://lists.swift.org/mailm
an/listinfo/swift-evolution
    >>>>>>
    >>>>>> _______________________________________________
    >>>>>> swift-evolution mailing list
    >>>>>> swift-evolution@swift.org <mailto:
swift-evolution@swift.org>
    <mailto: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.o
>
    <mailto: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
>
    <mailto: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>
    <mailto: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 <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

anandabits · February 18, 2017, 2:01am

Here, a function call is an _intentional_ act. Writing a function not meant to be called is an _intentional_ act. It is strange that you would demand the compiler to stand between two of your own intentional acts.

Yesterday I stated one intention. Today I (or a coworker) act with a contradictory intention.

One of these intentions, or some underlying assumption, must be in error.

Must it? Contradiction != error. I can simultaneously not want to expose a member as the vendor of the API *and* want to invoke the same member as the consumer of the API. Why must I be in error?

Why would I want to rely on a human to notice the error, if I can make the compiler do it?

It is normal to want the compiler to catch my errors. It is strange to prefer finding errors manually.

I can agree that compilers should catch errors. I want to persuade you that what we are talking about here does not fall into the category of error.

I don't view it so much as an error as I do a great tool to communicate compiler verified intent across time (to future readers and to your future self). As with many things in programming, the value of this is subjective (or at least subject of plentiful debate). I personally find it quite useful and it's clear that I am not alone. On the other hand, it's clear that many people don't find it terribly useful.

···

Sent from my iPad

On Feb 17, 2017, at 6:44 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

On Fri, Feb 17, 2017 at 5:49 PM, Rob Mayoff via swift-evolution <swift-evolution@swift.org> wrote:

On Fri, Feb 17, 2017 at 3:56 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

You might persuade me that the cost (in language complexity) of having the compiler detect the contradiction outweighs the benefit.

But I doubt you can persuade me that the detection has no benefit.

_______________________________________________
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

hartbit · February 19, 2017, 1:55pm

It is closer, but it's not a goal for Swift to always follow conventions of other languages. It's useful sometimes. But in this case it goes directly against the philosophy of Swift's extension feature. Swift should be allowed to go against the norm when it serves the languages. And in this case, if only one private should exist, it's the file-s open one.

···

On 19 Feb 2017, at 10:20, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote:

The current private is closer to other languages than the previous one we had which now has in fileprivate a better name.

Panajev · February 20, 2017, 8:39am

Please, almost anything but going back to the horrible Objective-C pattern of private headers (that end up included on in the implementation files) :/.

Seriously, that was always my issue with that blog post, assuming that the Objective-C way of dealing with this issue was something worth moving forward and not a path to massively improve upon or to avoid.

···

Sent from my iPhone

On 20 Feb 2017, at 08:30, Jonathan Hull via swift-evolution <swift-evolution@swift.org> wrote:

On Feb 19, 2017, at 7:29 PM, David Waite via swift-evolution <swift-evolution@swift.org> wrote:

A third point (which is a bit more complex/convoluted) is that fileprivate remained an essential language feature because it allows implementation in extensions, and allows a simple “friend”-like feature where types that need access to implementation details due to higher coupling could be bundled into the same file. Outside of a desire of a scoped ‘private’ simply to match the behavior of certain other languages, private is used to hide implementation details from other parts of a file, while file private exposes them within the file.

There is a potential that file-private can lead to an explosion of complexity due to a large amount of “friendly types” being bundled into the same file. In that sense, ‘private’ was wrong because it was adding complexity at the file level, when really a new access level would possibly have been more productive to define at the at the small-group-of-files level - either via a friend access level or submodules. We still have the potential of unmanageable files due to friend types, but any additional access levels to aid with this problem would have to be weighed against a now significantly more complex access model including file and scoped private. In that sense, the inclusion of scoped private may indeed be harmful in that it increases the challenge of much more useful access levels being added to the language.

This is the core of what I have been saying. If we don’t address this need of “friendly types” in a swift-y way, we will have to keep coming back to the drawing board (either for “friend” or “protected” or “submodules”). I really like swift 2 private, but it did cause long files because all of the extensions and friends had to be stuck in the same file. What we are really missing is something that has the connotation similar to private, but allows access where needed.

I agree with most of what was said in this blog post from the swift devs:
Access Control and protected - Swift Blog - Apple Developer

The main exception is that I disagree that ‘internal’ maps to the ObjC case where a second header was used (it doesn’t, and that is what is causing all of this trouble). Because internal is the default, it feels much too easy to accidentally use parts of a type which should only be used by extensions/subclasses/friend types. Remember, in an app (as opposed to a framework), internal is basically equivalent to public. With the second header, users of the contents of that header had to explicitly include it, which meant there was no chance of accidental use.

What we need is something which maps to that second header case while still keeping everything conceptually simple and swift-y.

Thanks,
Jon

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

anandabits · February 19, 2017, 3:16pm

The current private is closer to other languages than the previous one we had which now has in fileprivate a better name.

It is closer, but it's not a goal for Swift to always follow conventions of other languages. It's useful sometimes. But in this case it goes directly against the philosophy of Swift's extension feature. Swift should be allowed to go against the norm when it serves the languages. And in this case, if only one private should exist, it's the file-s open one.

Yes, I think making private not work well with extensions was the "actively harmful" aspect of SE-0025. Scoped access itself is not actively harmful and should not be removed, but it could be renamed so that private works the way people want it to again.

···

Sent from my iPad

On Feb 19, 2017, at 7:55 AM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:

On 19 Feb 2017, at 10:20, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote:

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

Panajev · February 19, 2017, 5:10pm

Good thing that both can exist then :). One day we may even get things such as abstract classes and be allowed to model abstentions wth classes and reference types better without it being seen as an attack to value types ;)..

···

Sent from my iPhone

On 19 Feb 2017, at 13:55, David Hart <david@hartbit.com> wrote:

On 19 Feb 2017, at 10:20, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote:

The current private is closer to other languages than the previous one we had which now has in fileprivate a better name.

It is closer, but it's not a goal for Swift to always follow conventions of other languages. It's useful sometimes. But in this case it goes directly against the philosophy of Swift's extension feature. Swift should be allowed to go against the norm when it serves the languages. And in this case, if only one private should exist, it's the file-s open one.

Jon_Hull · February 20, 2017, 8:46am

I didn’t say we should have headers, I said we need something that maps to those use cases in a swift-y way.

Just being able to mark something as internal to the type, and a way to opt-in to seeing those things within a particular file.

Thanks,
Jon

···

On Feb 20, 2017, at 12:39 AM, Goffredo Marocchi <panajev@gmail.com> wrote:

Please, almost anything but going back to the horrible Objective-C pattern of private headers (that end up included on in the implementation files) :/.

Seriously, that was always my issue with that blog post, assuming that the Objective-C way of dealing with this issue was something worth moving forward and not a path to massively improve upon or to avoid.

Sent from my iPhone

On 20 Feb 2017, at 08:30, Jonathan Hull via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Feb 19, 2017, at 7:29 PM, David Waite via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

A third point (which is a bit more complex/convoluted) is that fileprivate remained an essential language feature because it allows implementation in extensions, and allows a simple “friend”-like feature where types that need access to implementation details due to higher coupling could be bundled into the same file. Outside of a desire of a scoped ‘private’ simply to match the behavior of certain other languages, private is used to hide implementation details from other parts of a file, while file private exposes them within the file.

There is a potential that file-private can lead to an explosion of complexity due to a large amount of “friendly types” being bundled into the same file. In that sense, ‘private’ was wrong because it was adding complexity at the file level, when really a new access level would possibly have been more productive to define at the at the small-group-of-files level - either via a friend access level or submodules. We still have the potential of unmanageable files due to friend types, but any additional access levels to aid with this problem would have to be weighed against a now significantly more complex access model including file and scoped private. In that sense, the inclusion of scoped private may indeed be harmful in that it increases the challenge of much more useful access levels being added to the language.

This is the core of what I have been saying. If we don’t address this need of “friendly types” in a swift-y way, we will have to keep coming back to the drawing board (either for “friend” or “protected” or “submodules”). I really like swift 2 private, but it did cause long files because all of the extensions and friends had to be stuck in the same file. What we are really missing is something that has the connotation similar to private, but allows access where needed.

I agree with most of what was said in this blog post from the swift devs:
Access Control and protected - Swift Blog - Apple Developer <Access Control and protected - Swift Blog - Apple Developer;

The main exception is that I disagree that ‘internal’ maps to the ObjC case where a second header was used (it doesn’t, and that is what is causing all of this trouble). Because internal is the default, it feels much too easy to accidentally use parts of a type which should only be used by extensions/subclasses/friend types. Remember, in an app (as opposed to a framework), internal is basically equivalent to public. With the second header, users of the contents of that header had to explicitly include it, which meant there was no chance of accidental use.

What we need is something which maps to that second header case while still keeping everything conceptually simple and swift-y.

Thanks,
Jon

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

Rien · February 20, 2017, 9:15am

Please, almost anything but going back to the horrible Objective-C pattern of private headers (that end up included on in the implementation files) :/.

Why not a best of both worlds?

Everything is open inside the project unless marked private (in the swift 2 sense, i.e. fileprivate)

If a project/module exports a library, the same applies, unless there is a “library access level control file”.

If a "library access level control file” is present, all external access defaults to private unless disclosed in the “library access level control file”.

With proper IDE support, creating a "library access level control file” would require only minimal effort.

This would allow cleaner source code as you do not have to specify every access level all the time, reduces cognitive load during programming and debugging, fits nicely in the progressive disclosure strategy, creates a more readable interface for API users etc etc.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: Balancingrock (Rien) · GitHub
Project: http://swiftfire.nl

···

On 20 Feb 2017, at 09:39, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote:

Seriously, that was always my issue with that blog post, assuming that the Objective-C way of dealing with this issue was something worth moving forward and not a path to massively improve upon or to avoid.

Sent from my iPhone

On 20 Feb 2017, at 08:30, Jonathan Hull via swift-evolution <swift-evolution@swift.org> wrote:

On Feb 19, 2017, at 7:29 PM, David Waite via swift-evolution <swift-evolution@swift.org> wrote:

A third point (which is a bit more complex/convoluted) is that fileprivate remained an essential language feature because it allows implementation in extensions, and allows a simple “friend”-like feature where types that need access to implementation details due to higher coupling could be bundled into the same file. Outside of a desire of a scoped ‘private’ simply to match the behavior of certain other languages, private is used to hide implementation details from other parts of a file, while file private exposes them within the file.

There is a potential that file-private can lead to an explosion of complexity due to a large amount of “friendly types” being bundled into the same file. In that sense, ‘private’ was wrong because it was adding complexity at the file level, when really a new access level would possibly have been more productive to define at the at the small-group-of-files level - either via a friend access level or submodules. We still have the potential of unmanageable files due to friend types, but any additional access levels to aid with this problem would have to be weighed against a now significantly more complex access model including file and scoped private. In that sense, the inclusion of scoped private may indeed be harmful in that it increases the challenge of much more useful access levels being added to the language.

This is the core of what I have been saying. If we don’t address this need of “friendly types” in a swift-y way, we will have to keep coming back to the drawing board (either for “friend” or “protected” or “submodules”). I really like swift 2 private, but it did cause long files because all of the extensions and friends had to be stuck in the same file. What we are really missing is something that has the connotation similar to private, but allows access where needed.

I agree with most of what was said in this blog post from the swift devs:
Access Control and protected - Swift Blog - Apple Developer

The main exception is that I disagree that ‘internal’ maps to the ObjC case where a second header was used (it doesn’t, and that is what is causing all of this trouble). Because internal is the default, it feels much too easy to accidentally use parts of a type which should only be used by extensions/subclasses/friend types. Remember, in an app (as opposed to a framework), internal is basically equivalent to public. With the second header, users of the contents of that header had to explicitly include it, which meant there was no chance of accidental use.

What we need is something which maps to that second header case while still keeping everything conceptually simple and swift-y.

Thanks,
Jon

_______________________________________________
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

masters3d · February 19, 2017, 7:25pm

Sent from my iPad

The current private is closer to other languages than the previous one we had which now has in fileprivate a better name.

It is closer, but it's not a goal for Swift to always follow conventions of other languages. It's useful sometimes. But in this case it goes directly against the philosophy of Swift's extension feature. Swift should be allowed to go against the norm when it serves the languages. And in this case, if only one private should exist, it's the file-s open one.

Yes, I think making private not work well with extensions was the "actively harmful" aspect of SE-0025. Scoped access itself is not actively harmful and should not be removed, but it could be renamed so that private works the way people want it to again.

I think this an excellent point. In your proposal you can also mention that perhaps the renaming on private to mean scope private was premature since the primary goal was to match other languages notion on private. The issue is that Swift's public does not match other languages public. Should we then also change Swift's public to mean the established meaning of public in other languages? By no means! Swift is different. We agree that scope private is useful to some people by we believe that it is the wrong default for Swift. It is actively harmful in that by making it the default it forces a programmer to think fileprivate the moment the want to extend a type and access their private members. This in turn forces every programmer to have to deal with two access modifiers before they even make anything public. We believe this goes against the swift centric feature of extensibility via extensions and the philosophy of "the complexity inherited in the language needs to be progressively disclosed". In the same way that public doesn't make classes open, private should not be scope private.

This will make it possible for people to lock down in steps instead of all together which doesn't work with extensions.

We need more examples to make this case.

···

On Feb 19, 2017, at 7:16 AM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

On Feb 19, 2017, at 7:55 AM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:

On 19 Feb 2017, at 10:20, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote:

_______________________________________________
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

hartbit · February 19, 2017, 5:14pm

Good thing that both can exist then :). One day we may even get things such as abstract classes and be allowed to model abstentions wth classes and reference types better without it being seen as an attack to value types ;)..

But if both exist, we are keeping two access levels that are quite similar to please two groups of people: people that are used to scoped-access from other languages and people who prefer an access level which works better with Swift’s idioms. It’s wasteful to keep two around IMHO.

···

On 19 Feb 2017, at 18:10, Goffredo Marocchi <panajev@gmail.com> wrote:

Sent from my iPhone

On 19 Feb 2017, at 13:55, David Hart <david@hartbit.com> wrote:

On 19 Feb 2017, at 10:20, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote:

The current private is closer to other languages than the previous one we had which now has in fileprivate a better name.

It is closer, but it's not a goal for Swift to always follow conventions of other languages. It's useful sometimes. But in this case it goes directly against the philosophy of Swift's extension feature. Swift should be allowed to go against the norm when it serves the languages. And in this case, if only one private should exist, it's the file-s open one.

Panajev · February 20, 2017, 9:22am

Ok, on this I can agree... and I will. It try to mention how judging things by how "Swifty" they are makes us seem like a cult... but then again we are programmers/engineers... that word may very well apply appropriately :).

···

Sent from my iPhone

On 20 Feb 2017, at 08:46, Jonathan Hull <jhull@gbis.com> wrote:

I didn’t say we should have headers, I said we need something that maps to those use cases in a swift-y way.

Just being able to mark something as internal to the type, and a way to opt-in to seeing those things within a particular file.

Thanks,
Jon

On Feb 20, 2017, at 12:39 AM, Goffredo Marocchi <panajev@gmail.com> wrote:

Please, almost anything but going back to the horrible Objective-C pattern of private headers (that end up included on in the implementation files) :/.

Seriously, that was always my issue with that blog post, assuming that the Objective-C way of dealing with this issue was something worth moving forward and not a path to massively improve upon or to avoid.

Sent from my iPhone

On 20 Feb 2017, at 08:30, Jonathan Hull via swift-evolution <swift-evolution@swift.org> wrote:

On Feb 19, 2017, at 7:29 PM, David Waite via swift-evolution <swift-evolution@swift.org> wrote:

A third point (which is a bit more complex/convoluted) is that fileprivate remained an essential language feature because it allows implementation in extensions, and allows a simple “friend”-like feature where types that need access to implementation details due to higher coupling could be bundled into the same file. Outside of a desire of a scoped ‘private’ simply to match the behavior of certain other languages, private is used to hide implementation details from other parts of a file, while file private exposes them within the file.

There is a potential that file-private can lead to an explosion of complexity due to a large amount of “friendly types” being bundled into the same file. In that sense, ‘private’ was wrong because it was adding complexity at the file level, when really a new access level would possibly have been more productive to define at the at the small-group-of-files level - either via a friend access level or submodules. We still have the potential of unmanageable files due to friend types, but any additional access levels to aid with this problem would have to be weighed against a now significantly more complex access model including file and scoped private. In that sense, the inclusion of scoped private may indeed be harmful in that it increases the challenge of much more useful access levels being added to the language.

This is the core of what I have been saying. If we don’t address this need of “friendly types” in a swift-y way, we will have to keep coming back to the drawing board (either for “friend” or “protected” or “submodules”). I really like swift 2 private, but it did cause long files because all of the extensions and friends had to be stuck in the same file. What we are really missing is something that has the connotation similar to private, but allows access where needed.

I agree with most of what was said in this blog post from the swift devs:
Access Control and protected - Swift Blog - Apple Developer

The main exception is that I disagree that ‘internal’ maps to the ObjC case where a second header was used (it doesn’t, and that is what is causing all of this trouble). Because internal is the default, it feels much too easy to accidentally use parts of a type which should only be used by extensions/subclasses/friend types. Remember, in an app (as opposed to a framework), internal is basically equivalent to public. With the second header, users of the contents of that header had to explicitly include it, which meant there was no chance of accidental use.

What we need is something which maps to that second header case while still keeping everything conceptually simple and swift-y.

Thanks,
Jon

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

Panajev · February 20, 2017, 9:25am

Thanks for the suggestion, I will give it some thought and may others will do the same.

My issue with this topic is that I feel there is a lot of emotion but not yet a clear agreed best path forward. We should also think about design and implementation opportunity cost, what are we not addressing/focusing on/designing by focusing on arguing loudly about reverting a change set?

···

Sent from my iPhone

On 20 Feb 2017, at 09:15, Rien <Rien@Balancingrock.nl> wrote:

On 20 Feb 2017, at 09:39, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote:

Please, almost anything but going back to the horrible Objective-C pattern of private headers (that end up included on in the implementation files) :/.

Why not a best of both worlds?

Everything is open inside the project unless marked private (in the swift 2 sense, i.e. fileprivate)

If a project/module exports a library, the same applies, unless there is a “library access level control file”.

If a "library access level control file” is present, all external access defaults to private unless disclosed in the “library access level control file”.

With proper IDE support, creating a "library access level control file” would require only minimal effort.

This would allow cleaner source code as you do not have to specify every access level all the time, reduces cognitive load during programming and debugging, fits nicely in the progressive disclosure strategy, creates a more readable interface for API users etc etc.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: Balancingrock (Rien) · GitHub
Project: http://swiftfire.nl

Seriously, that was always my issue with that blog post, assuming that the Objective-C way of dealing with this issue was something worth moving forward and not a path to massively improve upon or to avoid.

Sent from my iPhone

On 20 Feb 2017, at 08:30, Jonathan Hull via swift-evolution <swift-evolution@swift.org> wrote:

On Feb 19, 2017, at 7:29 PM, David Waite via swift-evolution <swift-evolution@swift.org> wrote:

A third point (which is a bit more complex/convoluted) is that fileprivate remained an essential language feature because it allows implementation in extensions, and allows a simple “friend”-like feature where types that need access to implementation details due to higher coupling could be bundled into the same file. Outside of a desire of a scoped ‘private’ simply to match the behavior of certain other languages, private is used to hide implementation details from other parts of a file, while file private exposes them within the file.

There is a potential that file-private can lead to an explosion of complexity due to a large amount of “friendly types” being bundled into the same file. In that sense, ‘private’ was wrong because it was adding complexity at the file level, when really a new access level would possibly have been more productive to define at the at the small-group-of-files level - either via a friend access level or submodules. We still have the potential of unmanageable files due to friend types, but any additional access levels to aid with this problem would have to be weighed against a now significantly more complex access model including file and scoped private. In that sense, the inclusion of scoped private may indeed be harmful in that it increases the challenge of much more useful access levels being added to the language.

This is the core of what I have been saying. If we don’t address this need of “friendly types” in a swift-y way, we will have to keep coming back to the drawing board (either for “friend” or “protected” or “submodules”). I really like swift 2 private, but it did cause long files because all of the extensions and friends had to be stuck in the same file. What we are really missing is something that has the connotation similar to private, but allows access where needed.

I agree with most of what was said in this blog post from the swift devs:
Access Control and protected - Swift Blog - Apple Developer

The main exception is that I disagree that ‘internal’ maps to the ObjC case where a second header was used (it doesn’t, and that is what is causing all of this trouble). Because internal is the default, it feels much too easy to accidentally use parts of a type which should only be used by extensions/subclasses/friend types. Remember, in an app (as opposed to a framework), internal is basically equivalent to public. With the second header, users of the contents of that header had to explicitly include it, which meant there was no chance of accidental use.

What we need is something which maps to that second header case while still keeping everything conceptually simple and swift-y.

Thanks,
Jon

_______________________________________________
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