Re: [swift-evolution] private & fileprivate

[Kevin Ballard via swift-evolution]

On Fri, Oct 14, 2016, at 02:54 PM, Nevin Brackett-Rozinsky via swift-evolution 
wrote:
> On Fri, Oct 14, 2016 at 11:51 AM, Daniel Duan  wrote:
>>
>>
>> On Oct 13, 2016, at 9:03 PM, Nevin Brackett-Rozinsky
>>  wrote:
>>> Daniel, I would be interested to hear what, exactly, are the
>>> benefits your project has realized from the new “private” compared
>>> to the old “private” (which is now called “fileprivate”).
>>
>> There's no amazing insight here. The benefit is more granular
>> control. The more people work on a project, the more useful this
>> becomes.
>>
>
> More granular control *within a single file*. That is where I have a
> hard time imagining the benefits, and thus am asking for details.
>
> If there are multiple types within a single file, it is usually
> because they need to share implementation details.

Just because they need to share some implementation details doesn't mean
they should share all of them. Or better yet, a private/fileprivate type
in a file doesn't have to share any implementation details, it can
define a proper API that it exposes to the rest of the file while
keeping its implementation details private, just as it would if it were
an internal or public type.

> The only things that I see which scope-based access (the new
> “private”) brings to the table are:
> • Scope-private members from other parts of the file are unavailable
> (and thus don’t show in autocomplete).
> • Different extensions of a type can have scope-private members with
> the same name as each other.
>
> The former seems negligible, because you are working *within the same
> file*. The API that a type vends within its own file is hardly worth
> optimizing for.
>
> And the latter I would say is an anti-feature. Using multiple
> different members with the same name in extensions just makes it
> harder to rearrange the implementation, because those scope-private
> members will collide if moved into the same extension.
>
> So I *really* don’t see the benefits. Yes, I understand that there is
> now more granular control over access within a single file. I am
> asking for examples of how that additional granularity provides
> *benefits*.

Just because you're within a single file doesn't mean you need to throw
away the principles of API design. Sure, it's not nearly as important as
something that's more widely-visible, but that's not the same thing as
saying it's not important at all. Careful control of implementation
details vs exposed API even within a single file is still useful, either
because it's much easier to make the type public if desired, or because
it makes any future refactoring much easier. And it also helps you to
reason about the code as you're looking at it, because when you're
looking at a private declaration, you only have to consider the
immediate enclosing scope, as opposed to a fileprivate declaration where
you have to consider the whole file.

-Kevin Ballard

>  On Fri, Oct 14, 2016 at 11:51 AM, Daniel Duan
>   wrote:
>>
>> You might as well ask "why not make everything public" if private and
>> fileprivate makes no difference to you.
>
> That is not a fair assertion at all. The API which a type vends to
> other files within its module, and to clients outside its module, are
> significant parts of a quality and maintainable design.
>
> I do not think the API which a type vends *within its own file*
> warrants such lofty prioritization.
>
>
>> On Fri, Oct 14, 2016 at 11:51 AM, Daniel Duan
>>  wrote:
>>>
>>>
>>> On Oct 13, 2016, at 9:03 PM, Nevin Brackett-Rozinsky
>>>  wrote:
>>>
>>> As I see it, two significant drawbacks of the new “private” are
>>> increased complexity in the access control model, and encumbrance of
>>> the old “private” with the unwieldy moniker “fileprivate”.
>>
>> The first drawback is a truism: every language addition of feature
>> makes it more complex.
>
> You can’t just write off the complexity cost like that. The new scope-
> based “private” access level brings *substantial* complexity, to both
> the implementation and the mental programming model. It creates
> *unutterable* access levels, where a scope can see a member of another
> scope, but cannot create its own member with the same access level.
>
>
>> On Fri, Oct 14, 2016 at 11:51 AM, Daniel Duan
>>  wrote:
>>
>>
>> So we need to measure the benefit with other costs, which brings us
>> to your second "drawback". I'm having a hard time understanding it.
>> Is it too hard to type? If so, as an Objective-C survivor I disagree.
>> The experience of reading code is harder and therefore more important
>> than that of authoring code. "fileprivate" was chosen over many other
>> alternatives because it's obvious to the reader. A shorter but
>> equally obvious name would have been nice. But "unwieldy" is not
>> enough reason to justify such source-breaking change at the moment.
>
> Right, 

Re: [swift-evolution] private & fileprivate

[ted van gaalen via swift-evolution]

in 10-15 years compilers/interpreters are merged and update themselves as AI.
so we can tell in human language what an app should do :o)

@Jean: can you explain that about extensions in this context (oop) ?

TedvG


ted van gaalen

> On 15 Oct 2016, at 21:44, Goffredo Marocchi  wrote:
> 
> We will see how this will fare one way or the other in say 10-15 years.
> 
> Sent from my iPhone
> 
>> On 15 Oct 2016, at 14:43, Jean-Daniel via swift-evolution 
>>  wrote:
>> 
>> 
>>> Le 13 oct. 2016 à 23:27, Ted F.A. van Gaalen  a 
>>> écrit :
>>> 
>>> Please do NOT drop the current distinction between *private* and 
>>> *fileprivate*
>>> as it is now in Swift 3
>>> It is needed for correct OOP.  
>>> 
>> 
>> That argument don’t apply for a language where you can structure your code 
>> in extensions as in Swift.
>> 
>> 
>> ___
>> 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

Re: [swift-evolution] private & fileprivate

[Goffredo Marocchi via swift-evolution]

We will see how this will fare one way or the other in say 10-15 years.

Sent from my iPhone

> On 15 Oct 2016, at 14:43, Jean-Daniel via swift-evolution 
>  wrote:
> 
> 
>> Le 13 oct. 2016 à 23:27, Ted F.A. van Gaalen  a écrit 
>> :
>> 
>> Please do NOT drop the current distinction between *private* and 
>> *fileprivate*
>> as it is now in Swift 3
>> It is needed for correct OOP.  
>> 
> 
> That argument don’t apply for a language where you can structure your code in 
> extensions as in Swift.
> 
> 
> ___
> 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

Re: [swift-evolution] private & fileprivate

[Jean-Daniel via swift-evolution]

> Le 13 oct. 2016 à 23:27, Ted F.A. van Gaalen  a écrit :
> 
> Please do NOT drop the current distinction between *private* and *fileprivate*
> as it is now in Swift 3
> It is needed for correct OOP.  
> 

That argument don’t apply for a language where you can structure your code in 
extensions as in Swift.


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

Re: [swift-evolution] private & fileprivate

[Nevin Brackett-Rozinsky via swift-evolution]

On Fri, Oct 14, 2016 at 11:51 AM, Daniel Duan  wrote:

>
> On Oct 13, 2016, at 9:03 PM, Nevin Brackett-Rozinsky <
> nevin.brackettrozin...@gmail.com> wrote:
>
> Daniel, I would be interested to hear what, exactly, are the benefits your
> project has realized from the new “private” compared to the old “private”
> (which is now called “fileprivate”).
>
> There's no amazing insight here. The benefit is more granular control. The
> more people work on a project, the more useful this becomes.
>

More granular control *within a single file*. That is where I have a hard
time imagining the benefits, and thus am asking for details.

If there are multiple types within a single file, it is usually because
they need to share implementation details.

The only things that I see which scope-based access (the new “private”)
brings to the table are:
• Scope-private members from other parts of the file are unavailable (and
thus don’t show in autocomplete).
• Different extensions of a type can have scope-private members with the
same name as each other.

The former seems negligible, because you are working *within the same
file*. The API that a type vends within its own file is hardly worth
optimizing for.

And the latter I would say is an anti-feature. Using multiple different
members with the same name in extensions just makes it harder to rearrange
the implementation, because those scope-private members will collide if
moved into the same extension.

So I *really* don’t see the benefits. Yes, I understand that there is now
more granular control over access within a single file. I am asking for
examples of how that additional granularity provides *benefits*.


 On Fri, Oct 14, 2016 at 11:51 AM, Daniel Duan  wrote:

> You might as well ask "why not make everything public" if private and
> fileprivate makes no difference to you.
>

That is not a fair assertion at all. The API which a type vends to other
files within its module, and to clients outside its module, are significant
parts of a quality and maintainable design.

I do not think the API which a type vends *within its own file* warrants
such lofty prioritization.



> On Fri, Oct 14, 2016 at 11:51 AM, Daniel Duan  wrote:
>
>>
>> On Oct 13, 2016, at 9:03 PM, Nevin Brackett-Rozinsky <
>> nevin.brackettrozin...@gmail.com> wrote:
>>
> As I see it, two significant drawbacks of the new “private” are increased
> complexity in the access control model, and encumbrance of the old
> “private” with the unwieldy moniker “fileprivate”.
>
> The first drawback is a truism: every language addition of feature makes
> it more complex.
>

You can’t just write off the complexity cost like that. The new scope-based
“private” access level brings *substantial* complexity, to both the
implementation and the mental programming model. It creates *unutterable*
access levels, where a scope can see a member of another scope, but cannot
create its own member with the same access level.


On Fri, Oct 14, 2016 at 11:51 AM, Daniel Duan  wrote:
>
> So we need to measure the benefit with other costs, which brings us to
> your second "drawback". I'm having a hard time understanding it. Is it too
> hard to type? If so, as an Objective-C survivor I disagree. The experience
> of reading code is harder and therefore more important than that of
> authoring code. "fileprivate" was chosen over many other alternatives
> because it's obvious to the reader. A shorter but equally obvious name
> would have been nice. But "unwieldy" is not enough reason to justify such
> source-breaking change at the moment.
>

Right, “unwieldy” is not enough to justify a source-breaking change. I
entirely agree.

It is the *complexity* of the current model that would justify the
source-breaking change, if it does not have real benefits which stand on
their own and outweigh the costs.

What unwieldiness *does* justify is a non-breaking change, such as
introducing “privy” (or something else) as a synonym for “fileprivate”,
then eventually deprecating and removing the latter.

• • •

I will also note that the principal practical effect of SE-0025 was
“Replace a small number of occurrences of ‘private’ with ‘fileprivate’.”

That is essentially all it did to source code. It brought a significant
increase to the complexity of the access control model, in order to make a
few member declarations lengthier and more awkward.

Maybe there are other benefits, but I have not seen them.

• • •

Let me reiterate my stance: if the new scope-based “private” has benefits
which outweigh its complexity cost, then we should keep it. Otherwise we
should get rid of scope-based access control and reinstate the old
file-based “private”.

Furthermore, we should rename “fileprivate” to something shorter and less
awkward, which will play nice with submodules. If “private” is off the
table then I propose “privy”, though I welcome other suggestions.

 Nevin

If the new “private” has brought 

Re: [swift-evolution] private & fileprivate

[Daniel Duan via swift-evolution]

> On Oct 13, 2016, at 9:03 PM, Nevin Brackett-Rozinsky 
>  wrote:
> 
> Daniel, I would be interested to hear what, exactly, are the benefits your 
> project has realized from the new “private” compared to the old “private” 
> (which is now called “fileprivate”).
> 

There's no amazing insight here. The benefit is more granular control. The more 
people work on a project, the more useful this becomes.

You might as well ask "why not make everything public" if private and 
fileprivate makes no difference to you.

> Were there problems caused by the old “private” that have been solved by the 
> new “private”? Major problems? Minor annoyances?
> 
> • • •
> 
> As I see it, two significant drawbacks of the new “private” are increased 
> complexity in the access control model, and encumbrance of the old “private” 
> with the unwieldy moniker “fileprivate”.
> 

The first drawback is a truism: every language addition of feature makes it 
more complex. So we need to measure the benefit with other costs, which brings 
us to your second "drawback". I'm having a hard time understanding it. Is it 
too hard to type? If so, as an Objective-C survivor I disagree. The experience 
of reading code is harder and therefore more important than that of authoring 
code. "fileprivate" was chosen over many other alternatives because it's 
obvious to the reader. A shorter but equally obvious name would have been nice. 
But "unwieldy" is not enough reason to justify such source-breaking change at 
the moment.


> If the new “private” has brought real benefits sufficient to outweigh its 
> complexity cost then I think it should stay, and if not it should go. Thus I 
> am curious to see what benefits it has in practice.
> 
> • • •
> 
> Regardless of whether the new “private” is pulling its weight, I believe we 
> should find a shorter name for “fileprivate”.
> 
> And I think Xiaodi has the right idea: whensoever in the future we decide to 
> introduce submodules, it would be best if they subsumed the file scope. In 
> essence, a submodule would be the mechanism for parceling out code which 
> currently must reside in a single file (because it relies on “fileprivate” 
> which is the old “private”).
> 
> That way a submodule could comprise several interrelated pieces which need to 
> share privy details, while preserving their natural separation into distinct 
> files. So it makes sense that we should find a replacement for “fileprivate” 
> which is copacetic to submodules.
> 
> Actually, now that I write it down, I wonder if perhaps “privy” might work as 
> a keyword. It is short, it means “being party to shared secret knowledge”, 
> and its spelling conveys a sense of “private-ish”.
> 
> The other ideas I’ve come up with have shortcomings, such as “local” which 
> has a pre-existing incompatible meaning in programming (otherwise it would be 
> great), or “folio” which is not an adjective (and also isn’t ideal for the 
> single-file case).
> 
> But “privy” just might work.
> 
> Nevin
> 
> 
>> On Thu, Oct 13, 2016 at 10:44 PM, Daniel Duan via swift-evolution 
>>  wrote:
>> I question the practicality of "use private heavily simply because I don’t 
>> want the burden of mixing private and fileprivate". In our experience in 
>> converting a very mature Swift application, we had no choice but to use both 
>> because we wanted private as much as possible but that's too restrictive in 
>> some cases. The granularity private and fileprivate provide is definitey a 
>> welcome change.
>> 
>> Daniel Duan
>> Sent from my iPhone
>> 
>>> On Oct 13, 2016, at 3:11 AM, David Hart via swift-evolution 
>>>  wrote:
>>> 
>>> 
> On 13 Oct 2016, at 08:25, Jean-Daniel via swift-evolution 
>  wrote:
> 
> 
> Le 13 oct. 2016 à 07:52, Chris Lattner via swift-evolution 
>  a écrit :
> 
> On Oct 12, 2016, at 9:56 PM, Russ Bishop via swift-evolution 
>  wrote:
 I actually consider it very lucky that most of our changes so far have 
 been fairly non-controversial. Everybody has a different idea of what 
 would make Swift a better language, and all of us well-meaning. But 
 when those ideas conflict, some group is going to end up unhappy. I'm 
 actually very glad that (a) we haven't had too many of these cases, 
 and (b) even when we have, people have been able to accept it and move 
 on to contributing to the next issue.
>>> 
>>> 
>>> Strong agreement here as well. This proposal has been litigated 
>>> numerous times already, and the bar for source-breaking changes is much 
>>> higher now. To effectively re-open the discussion would require a 
>>> proposal that significant changes the model with a lot of evidence that 
>>> such a new model is a drastic improvement over what we have 

Re: [swift-evolution] private & fileprivate

[Jeremy Pereira via swift-evolution]

> On 14 Oct 2016, at 09:35, Jamie Lemon via swift-evolution 
>  wrote:
> 
> I agree with Ted that I would have expected the inner members of a class to 
> be private by default. (Not a big deal if I have to explicitly prefix most of 
> my concerned vars now - but it is just different to what I would have 
> expected). Certainly, in the past, I would be more used to having to 
> explicitly define chosen vars as “public” ( e.g. in the past world of 
> Objective C I  was used to defining selected vars with @synthesize to “open 
> them up" ) 

@synthesize has nothing to do with instance variable visibility, all it did was 
synthesise an instance variable to back a property (which  was really a pair of 
methods). In Objective-C instance variables are protected (i.e. visible to 
subclasses) by default and all methods (which by extension means properties 
too) are public. 

The waters are somewhat muddied by the fact that the Objective-C compiler can 
only see declarations in the current code unit and any imports, so you can hide 
non private instance variables by putting them in the @implementation and you 
can hide properties and methods by declaring them in a category that isn’t in 
an import. However, anybody can defeat the second of these by declaring their 
own category with the hidden method signatures in it.

private by default is comparatively rare, it’s not true of Java, C#, 
Javascript, or Python. Having said, that it does make sense to me but would be 
an enormous breaking change for Swift now.

I was against the private/fileprivate distinction when it was proposed, but now 
it’s done and I’ve applied it to my own code, I am fine with it. I did a global 
replace of fileprivate with private in one of my largest converted source files 
and experienced only one breakage. I think there is a use case for fileprivate, 
so I wouldn’t want to get rid of it but I think it’s rare enough that the 
ugliness of its name doesn’t bother me. 

> 
> ___
> 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

Re: [swift-evolution] private & fileprivate

[Ted F.A. van Gaalen via swift-evolution]

Most disturbing, 
What are you trying to achieve?

Well, I can be a little harsh at times too, perhaps at times
when I do not fully understand or misinterpret situations or people.
in that case I will admit my shortcoming and apologise if necessary.

However, you are being very negative, rude and insulting,
Btw, I also work with Smalltalk and assure that you are 
completely out of touch with the Smalltalk community
which is very friendly and social and so is the Swift community.

I see no need to further converse with you.

TedvG






> On 14 Oct 2016, at 02:14, Trans  wrote:
> 
> Sorry, that was a little harsh. I just think there are a lot of
> opinions here based on personal biases and not necessary the best
> prior experiences. If you want good OOP it is best to let people with
> *real* OOP experience, like SmallTalk, work it out.

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

Re: [swift-evolution] private & fileprivate

[Charles Srstka via swift-evolution]

> On Oct 13, 2016, at 1:25 AM, Jean-Daniel via swift-evolution 
>  wrote:
> 
> I don’t think monitoring the usage of private vs fileprivate is fair. By 
> default, people will use private until they encounter visibility issues and 
> discover they need to change to fileprivate. So private will probably being 
> use far more than fileprivate.
> Nonetheless it does not mean people chosen private because it effectively 
> reduce the visibility to the class scope, but just because it is easier to 
> discover and to type than fileprivate and fit in many cases.

How is that an argument against private, though? If private is used far more 
often than fileprivate, then this suggests that the vast amount of the time, 
the scope it provides is what is appropriate. The enlarged scope provided by 
fileprivate, then, is needed for what are essentially edge cases. It makes 
little sense, to my mind, to replace the mainstream option with the niche one.

Charles

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

Re: [swift-evolution] private & fileprivate

[Goffredo Marocchi via swift-evolution]

Well, this is some good attitude ;).

Sent from my iPhone

> On 14 Oct 2016, at 00:50, Trans via swift-evolution 
>  wrote:
> 
> On Thu, Oct 13, 2016 at 5:27 PM, Ted F.A. van Gaalen via
> swift-evolution  wrote:
>> Please do NOT drop the current distinction between *private* and
>> *fileprivate*
>> as it is now in Swift 3
>> It is needed for correct OOP.
> 
> Sorry, but that is laughable. So far I haven't seen a sole on here
> that seems to really know anything about OOP. You all are just copying
> and extrapolating on ObjC/C++/Java. Which got it all sorts of wrong
> from the get go.
> 
> Go learn you some SmallTalk for the greater good.
> ___
> 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

Re: [swift-evolution] private & fileprivate

[Jamie Lemon via swift-evolution]

I agree with Ted that I would have expected the inner members of a class to be 
private by default. (Not a big deal if I have to explicitly prefix most of my 
concerned vars now - but it is just different to what I would have expected). 
Certainly, in the past, I would be more used to having to explicitly define 
chosen vars as “public” ( e.g. in the past world of Objective C I  was used to 
defining selected vars with @synthesize to “open them up" )

On 13 Oct 2016, at 22:27, Ted F.A. van Gaalen via swift-evolution 
> wrote:

Please do NOT drop the current distinction between *private* and *fileprivate*
as it is now in Swift 3
It is needed for correct OOP.

As written before, but now a bit more compact, I hope:

I would like to have the inner members of a class as default private,
(not fileprivate)  that is, that each entity inside the class body is not 
visible
in the outer scope. not even in the same file!

I would only reveal entities of a class to the outer scope that are 
needed.there.
(as is the case with class properties in Objective-C and most other OOP 
supporting languages)

This is what I have to do now,
Each and every entity that I wish to keep hidden
I have to prefix with *private*: like in this example class:
This is tedious and should be unnecessary.

class TG3DGauge: SCNNode
{

private var needles = [SCNNode]()
private var fmtStr = “" // private should be the default!

var value: CGFloat = 0  // access default “internal”! Visible to the 
outside world.
{
didSet  // trigger value change, rotate needles etc.
{
valueChange()
}
}

private var nodeUnitText = SCNNode()
private var nodeValueText = SCNNode()

private var valRange: ClosedRange = (0...100.0)
private var valScaleFactor: CGFloat = 1

// etc. much more stuff here and
// most of it should be private, that is
// only visible within the class body!
.
.
} // end class TG3DGauge

If I don’t specify an access modifier, then the default
for the items defined in classes is *internal*,
which means that these items are visible in the whole application source.

However, this is only desirable for items that I want to
reveal explicitly, of course.
That is exactly why I need the *private* access modifier as it is now
and not *fileprivate*
So I am very glad that this access modifier *private* finally became
available in Swift 3

In my classes, *private* is probably the most used keyword, but
*private* should be the default for entities within a class body
just like it is for entities within functions.

As far as I know, prefixing with *private* is the only solution in Swift to 
protect
functions, vars etc. in my class against unwanted access
from the outer scope. I think this is not the way it should be.

Making all entities in a class private prevents this.
and offers also reasonable protection against
the Fragile Base Class problem, (thanks Chris for url) :
 https://en.wikipedia.org/wiki/Fragile_base_class

A solution for as it is now, albeit not a perfect one would be,
to have some sort of access modifier which defines
all items within the class to be private by default.
perhaps the keyword *closedscope* like in this example:

closedscope class TG3DGauge: SCNNode
{

var needles = [SCNNode]()  // is now private by default
var fmtStr = “"// is now private by default

public var value: CGFloat = 0 // Public!! visible outside class
   // “fileprivate" or “internal”  can also be used.
{
didSet  // trigger value change, rotate needles etc.
{
valueChange()
}
}

var nodeUnitText = SCNNode()  // is now private by default
var nodeValueText = SCNNode() // is now private by default

//etc.


Again, for this reasons, don’t drop the distinction between
between *fileprivate* and *private*
if this is done, there is afaics no way to protect items within a class body.
Leave it as it is now, please. (also to prevent source breaking as well)

(btw, the above TG3DGauge class is a perfect example:
With real gauges it would not be a good idea if one can touch
the needles and gears inside the gauge’s casing,
which is exactly the case with OOP. e.g.
In my class example people would e.g. be able to set the angle
from needles (if not declared private)  directly, without updating the value.)


TedvG
www.tedvg.com  (see my gauges from above class here)



Le 13 oct. 2016 à 07:52, Chris Lattner via swift-evolution 
> a écrit :

On Oct 12, 2016, at 9:56 PM, Russ Bishop via swift-evolution 
 
> wrote:
I actually consider it very lucky that most of our changes so far have been 
fairly non-controversial. Everybody has a different idea of what 

Re: [swift-evolution] private & fileprivate

[Rien via swift-evolution]

> On 14 Oct 2016, at 06:03, Nevin Brackett-Rozinsky via swift-evolution 
>  wrote:
> 
> Daniel, I would be interested to hear what, exactly, are the benefits your 
> project has realized from the new “private” compared to the old “private” 
> (which is now called “fileprivate”).
> 
> Were there problems caused by the old “private” that have been solved by the 
> new “private”? Major problems? Minor annoyances?
> 

Yes please.
To me, access levels seem to be more about communication than about problem 
solving. I.e. if I make something ‘private’ then I am communicating to the 
outside world “hey don’t touch this”. And if it ain’t private then “go ahead, 
change this any way you like”. But imo they don’t solve an actual programming 
problem. No?

Rien



> • • •
> 
> As I see it, two significant drawbacks of the new “private” are increased 
> complexity in the access control model, and encumbrance of the old “private” 
> with the unwieldy moniker “fileprivate”.
> 
> If the new “private” has brought real benefits sufficient to outweigh its 
> complexity cost then I think it should stay, and if not it should go. Thus I 
> am curious to see what benefits it has in practice.
> 
> • • •
> 
> Regardless of whether the new “private” is pulling its weight, I believe we 
> should find a shorter name for “fileprivate”.
> 
> And I think Xiaodi has the right idea: whensoever in the future we decide to 
> introduce submodules, it would be best if they subsumed the file scope. In 
> essence, a submodule would be the mechanism for parceling out code which 
> currently must reside in a single file (because it relies on “fileprivate” 
> which is the old “private”).
> 
> That way a submodule could comprise several interrelated pieces which need to 
> share privy details, while preserving their natural separation into distinct 
> files. So it makes sense that we should find a replacement for “fileprivate” 
> which is copacetic to submodules.
> 
> Actually, now that I write it down, I wonder if perhaps “privy” might work as 
> a keyword. It is short, it means “being party to shared secret knowledge”, 
> and its spelling conveys a sense of “private-ish”.
> 
> The other ideas I’ve come up with have shortcomings, such as “local” which 
> has a pre-existing incompatible meaning in programming (otherwise it would be 
> great), or “folio” which is not an adjective (and also isn’t ideal for the 
> single-file case).
> 
> But “privy” just might work.
> 
> Nevin
> 
> 
> On Thu, Oct 13, 2016 at 10:44 PM, Daniel Duan via swift-evolution 
>  wrote:
> I question the practicality of "use private heavily simply because I don’t 
> want the burden of mixing private and fileprivate". In our experience in 
> converting a very mature Swift application, we had no choice but to use both 
> because we wanted private as much as possible but that's too restrictive in 
> some cases. The granularity private and fileprivate provide is definitey a 
> welcome change.
> 
> Daniel Duan
> Sent from my iPhone
> 
> On Oct 13, 2016, at 3:11 AM, David Hart via swift-evolution 
>  wrote:
> 
>> 
>>> On 13 Oct 2016, at 08:25, Jean-Daniel via swift-evolution 
>>>  wrote:
>>> 
>>> 
 Le 13 oct. 2016 à 07:52, Chris Lattner via swift-evolution 
  a écrit :
 
 On Oct 12, 2016, at 9:56 PM, Russ Bishop via swift-evolution 
  wrote:
>>> I actually consider it very lucky that most of our changes so far have 
>>> been fairly non-controversial. Everybody has a different idea of what 
>>> would make Swift a better language, and all of us well-meaning. But 
>>> when those ideas conflict, some group is going to end up unhappy. I'm 
>>> actually very glad that (a) we haven't had too many of these cases, and 
>>> (b) even when we have, people have been able to accept it and move on 
>>> to contributing to the next issue.
>> 
>> Strong agreement here as well. This proposal has been litigated numerous 
>> times already, and the bar for source-breaking changes is much higher 
>> now. To effectively re-open the discussion would require a proposal that 
>> significant changes the model with a lot of evidence that such a new 
>> model is a drastic improvement over what we have now. “Back out SE-0025” 
>> is not a viable option now.
>> 
>>  - Doug
> 
> Not really. This proposal could be backed out without source-breaking 
> changes by treating private as a synonym for fileprivate and we’d have 
> Swift 2 behavior without breaking source. If the core team doesn’t want 
> to consider that then we can just move on and live with it. 
 
 Not speaking for the core team, just MHO:
 
 I agree with Russ here, and with others who have said upthread that the 
 “thing that has changed” is that we are starting to get 

Re: [swift-evolution] private & fileprivate

[Nevin Brackett-Rozinsky via swift-evolution]

Daniel, I would be interested to hear what, exactly, are the benefits your
project has realized from the new “private” compared to the old “private”
(which is now called “fileprivate”).

Were there problems caused by the old “private” that have been solved by
the new “private”? Major problems? Minor annoyances?

• • •

As I see it, two significant drawbacks of the new “private” are increased
complexity in the access control model, and encumbrance of the old
“private” with the unwieldy moniker “fileprivate”.

If the new “private” has brought real benefits sufficient to outweigh its
complexity cost then I think it should stay, and if not it should go. Thus
I am curious to see what benefits it has in practice.

• • •

Regardless of whether the new “private” is pulling its weight, I believe we
should find a shorter name for “fileprivate”.

And I think Xiaodi has the right idea: whensoever in the future we decide
to introduce submodules, it would be best if they subsumed the file scope.
In essence, a submodule would be the mechanism for parceling out code which
currently must reside in a single file (because it relies on “fileprivate”
which is the old “private”).

That way a submodule could comprise several interrelated pieces which need
to share privy details, while preserving their natural separation into
distinct files. So it makes sense that we should find a replacement for
“fileprivate” which is copacetic to submodules.

Actually, now that I write it down, I wonder if perhaps “privy” might work
as a keyword. It is short, it means “being party to shared secret
knowledge”, and its spelling conveys a sense of “private-ish”.

The other ideas I’ve come up with have shortcomings, such as “local” which
has a pre-existing incompatible meaning in programming (otherwise it would
be great), or “folio” which is not an adjective (and also isn’t ideal for
the single-file case).

But “privy” just might work.

Nevin


On Thu, Oct 13, 2016 at 10:44 PM, Daniel Duan via swift-evolution <
swift-evolution@swift.org> wrote:

> I question the practicality of "use private heavily simply because I
> don’t want the burden of mixing private and fileprivate". In our experience
> in converting a very mature Swift application, we had no choice but to use
> both because we wanted private as much as possible but that's too
> restrictive in some cases. The granularity private and fileprivate provide
> is definitey a welcome change.
>
> Daniel Duan
> Sent from my iPhone
>
> On Oct 13, 2016, at 3:11 AM, David Hart via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On 13 Oct 2016, at 08:25, Jean-Daniel via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> Le 13 oct. 2016 à 07:52, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
> On Oct 12, 2016, at 9:56 PM, Russ Bishop via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I actually consider it very lucky that most of our changes so far have
> been fairly non-controversial. Everybody has a different idea of what would
> make Swift a better language, and all of us well-meaning. But when those
> ideas conflict, some group is going to end up unhappy. I'm actually very
> glad that (a) we haven't had too many of these cases, and (b) even when we
> have, people have been able to accept it and move on to contributing to the
> next issue.
>
>
> Strong agreement here as well. This proposal has been litigated numerous
> times already, and the bar for source-breaking changes is much higher now.
> To effectively re-open the discussion would require a proposal that
> significant changes the model with a lot of evidence that such a new model
> is a drastic improvement over what we have now. “Back out SE-0025” is not a
> viable option now.
>
> - Doug
>
>
> Not really. This proposal could be backed out without source-breaking
> changes by treating private as a synonym for fileprivate and we’d have
> Swift 2 behavior without breaking source. If the core team doesn’t want to
> consider that then we can just move on and live with it.
>
>
> Not speaking for the core team, just MHO:
>
> I agree with Russ here, and with others who have said upthread that the
> “thing that has changed” is that we are starting to get usage experience
> with fileprivate vs private.  I think we all understand the value of having
> fewer access control levels, and so if “private” isn’t conceptually pulling
> its weight, then it is reasonable to consider phasing it out.
>
> That said, there is no specific rush to have this discussion, and I think
> it is reasonable to put a pretty high burden of proof on someone who wants
> to drive such a proposal.  For example, if we had the discussion in the
> spring timeframe, we should have a pretty large body of Swift 3 code
> readily at hand (e.g. SwiftPM packages and other various github repos).
>
> Given that, it should be easy enough to see how widely private is actually
> being used in practice.  If it is very rare, then the 

Re: [swift-evolution] private & fileprivate

[Hooman Mehr via swift-evolution]

fileprivate  is not essential but I also would like to defend keeping it, at 
least for now. 

I find it useful in practice. In some cases, I can’t put a declaration in the 
global file scope (where fileprivate and private are essentially the same 
thing). For example, for organizational reasons I may have multiple protocol 
conformance extension blocks which use some “private” functions that are useful 
in more than one of those protocol extensions in the same file. 

In the future, the  introduction of submodules and having submodule-internal 
scope may eliminate most use cases for fileprivate. But still, we may not want 
the overhead of introducing submodules just to get the effect of a simple 
fileprivate.


> On Oct 13, 2016, at 7:44 PM, Daniel Duan via swift-evolution 
>  wrote:
> 
> I question the practicality of "use private heavily simply because I don’t 
> want the burden of mixing private and fileprivate". In our experience in 
> converting a very mature Swift application, we had no choice but to use both 
> because we wanted private as much as possible but that's too restrictive in 
> some cases. The granularity private and fileprivate provide is definitey a 
> welcome change.
> 
> Daniel Duan
> Sent from my iPhone
> 
> On Oct 13, 2016, at 3:11 AM, David Hart via swift-evolution 
> > wrote:
> 
>> 
>>> On 13 Oct 2016, at 08:25, Jean-Daniel via swift-evolution 
>>> > wrote:
>>> 
>>> 
 Le 13 oct. 2016 à 07:52, Chris Lattner via swift-evolution 
 > a écrit :
 
 On Oct 12, 2016, at 9:56 PM, Russ Bishop via swift-evolution 
 > wrote:
>>> I actually consider it very lucky that most of our changes so far have 
>>> been fairly non-controversial. Everybody has a different idea of what 
>>> would make Swift a better language, and all of us well-meaning. But 
>>> when those ideas conflict, some group is going to end up unhappy. I'm 
>>> actually very glad that (a) we haven't had too many of these cases, and 
>>> (b) even when we have, people have been able to accept it and move on 
>>> to contributing to the next issue.
>> 
>> 
>> Strong agreement here as well. This proposal has been litigated numerous 
>> times already, and the bar for source-breaking changes is much higher 
>> now. To effectively re-open the discussion would require a proposal that 
>> significant changes the model with a lot of evidence that such a new 
>> model is a drastic improvement over what we have now. “Back out SE-0025” 
>> is not a viable option now.
>> 
>>  - Doug
> 
> Not really. This proposal could be backed out without source-breaking 
> changes by treating private as a synonym for fileprivate and we’d have 
> Swift 2 behavior without breaking source. If the core team doesn’t want 
> to consider that then we can just move on and live with it. 
 
 Not speaking for the core team, just MHO:
 
 I agree with Russ here, and with others who have said upthread that the 
 “thing that has changed” is that we are starting to get usage experience 
 with fileprivate vs private.  I think we all understand the value of 
 having fewer access control levels, and so if “private” isn’t conceptually 
 pulling its weight, then it is reasonable to consider phasing it out.
 
 That said, there is no specific rush to have this discussion, and I think 
 it is reasonable to put a pretty high burden of proof on someone who wants 
 to drive such a proposal.  For example, if we had the discussion in the 
 spring timeframe, we should have a pretty large body of Swift 3 code 
 readily at hand (e.g. SwiftPM packages and other various github repos).
 
 Given that, it should be easy enough to see how widely private is actually 
 being used in practice.  If it is very rare, then the argument to ditch it 
 (make it a synonym for fileprivate, and eventually phasing out 
 fileprivate) is strong.  If lots of people are using private and only some 
 are using fileprivate, then the discussion is quite different.
 
 -Chris
>>> 
>>> I don’t think monitoring the usage of private vs fileprivate is fair. By 
>>> default, people will use private until they encounter visibility issues and 
>>> discover they need to change to fileprivate. So private will probably being 
>>> use far more than fileprivate.
>>> Nonetheless it does not mean people chosen private because it effectively 
>>> reduce the visibility to the class scope, but just because it is easier to 
>>> discover and to type than fileprivate and fit in many cases.
>>> 
>>> I tend to write class will all ivars private by default (as it is a 
>>> sensible 

Re: [swift-evolution] private & fileprivate

[Daniel Duan via swift-evolution]

I question the practicality of "use private heavily simply because I don’t want 
the burden of mixing private and fileprivate". In our experience in converting 
a very mature Swift application, we had no choice but to use both because we 
wanted private as much as possible but that's too restrictive in some cases. 
The granularity private and fileprivate provide is definitey a welcome change.

Daniel Duan
Sent from my iPhone

> On Oct 13, 2016, at 3:11 AM, David Hart via swift-evolution 
>  wrote:
> 
> 
>>> On 13 Oct 2016, at 08:25, Jean-Daniel via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> Le 13 oct. 2016 à 07:52, Chris Lattner via swift-evolution 
>>>  a écrit :
>>> 
>>> On Oct 12, 2016, at 9:56 PM, Russ Bishop via swift-evolution 
>>>  wrote:
>> I actually consider it very lucky that most of our changes so far have 
>> been fairly non-controversial. Everybody has a different idea of what 
>> would make Swift a better language, and all of us well-meaning. But when 
>> those ideas conflict, some group is going to end up unhappy. I'm 
>> actually very glad that (a) we haven't had too many of these cases, and 
>> (b) even when we have, people have been able to accept it and move on to 
>> contributing to the next issue.
> 
> 
> Strong agreement here as well. This proposal has been litigated numerous 
> times already, and the bar for source-breaking changes is much higher 
> now. To effectively re-open the discussion would require a proposal that 
> significant changes the model with a lot of evidence that such a new 
> model is a drastic improvement over what we have now. “Back out SE-0025” 
> is not a viable option now.
> 
>   - Doug
 
 Not really. This proposal could be backed out without source-breaking 
 changes by treating private as a synonym for fileprivate and we’d have 
 Swift 2 behavior without breaking source. If the core team doesn’t want to 
 consider that then we can just move on and live with it. 
>>> 
>>> Not speaking for the core team, just MHO:
>>> 
>>> I agree with Russ here, and with others who have said upthread that the 
>>> “thing that has changed” is that we are starting to get usage experience 
>>> with fileprivate vs private.  I think we all understand the value of having 
>>> fewer access control levels, and so if “private” isn’t conceptually pulling 
>>> its weight, then it is reasonable to consider phasing it out.
>>> 
>>> That said, there is no specific rush to have this discussion, and I think 
>>> it is reasonable to put a pretty high burden of proof on someone who wants 
>>> to drive such a proposal.  For example, if we had the discussion in the 
>>> spring timeframe, we should have a pretty large body of Swift 3 code 
>>> readily at hand (e.g. SwiftPM packages and other various github repos).
>>> 
>>> Given that, it should be easy enough to see how widely private is actually 
>>> being used in practice.  If it is very rare, then the argument to ditch it 
>>> (make it a synonym for fileprivate, and eventually phasing out fileprivate) 
>>> is strong.  If lots of people are using private and only some are using 
>>> fileprivate, then the discussion is quite different.
>>> 
>>> -Chris
>> 
>> I don’t think monitoring the usage of private vs fileprivate is fair. By 
>> default, people will use private until they encounter visibility issues and 
>> discover they need to change to fileprivate. So private will probably being 
>> use far more than fileprivate.
>> Nonetheless it does not mean people chosen private because it effectively 
>> reduce the visibility to the class scope, but just because it is easier to 
>> discover and to type than fileprivate and fit in many cases.
>> 
>> I tend to write class will all ivars private by default (as it is a sensible 
>> default), and then, when I start to write extensions and other parts, I have 
>> to switch to fileprivate for a bunch of ivars. It create an inconsistent 
>> mess in my ivars declaration as it is difficult to know if an ivar is 
>> private because I has to be, or because I didn’t encounter a case that need 
>> it to be fileprivate instead.
>> 
>> Honestly, I don’t see any value in the introduction of fileprivate.
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> I also agree that monitoring the usage of private vs fileprivate is not fair. 
> I now use private heavily simply because I don’t want the burden of mixing 
> private and fileprivate (and find the name of fileprivate slightly 
> verbose/ugly). But that does not mean I would vote for keeping private. I 
> would still vote for going back to Swift 2 behaviour. But I agree that we can 
> wait until the summer to look at this again.
> 

Re: [swift-evolution] private & fileprivate

[Trans via swift-evolution]

Sorry, that was a little harsh. I just think there are a lot of
opinions here based on personal biases and not necessary the best
prior experiences. If you want good OOP it is best to let people with
*real* OOP experience, like SmallTalk, work it out.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] private & fileprivate

[Ted F.A. van Gaalen via swift-evolution]

Please do NOT drop the current distinction between *private* and *fileprivate*
as it is now in Swift 3
It is needed for correct OOP.  

As written before, but now a bit more compact, I hope:

I would like to have the inner members of a class as default private, 
(not fileprivate)  that is, that each entity inside the class body is not 
visible 
in the outer scope. not even in the same file!

I would only reveal entities of a class to the outer scope that are 
needed.there.
(as is the case with class properties in Objective-C and most other OOP 
supporting languages)

This is what I have to do now,
Each and every entity that I wish to keep hidden
I have to prefix with *private*: like in this example class: 
This is tedious and should be unnecessary.

class TG3DGauge: SCNNode
{

private var needles = [SCNNode]()
private var fmtStr = “" // private should be the default!

var value: CGFloat = 0  // access default “internal”! Visible to the 
outside world.
{
didSet  // trigger value change, rotate needles etc.
{
valueChange()
}
}

private var nodeUnitText = SCNNode()
private var nodeValueText = SCNNode()

private var valRange: ClosedRange = (0...100.0)
private var valScaleFactor: CGFloat = 1

// etc. much more stuff here and
// most of it should be private, that is
// only visible within the class body!
.
.
} // end class TG3DGauge

If I don’t specify an access modifier, then the default
for the items defined in classes is *internal*,
which means that these items are visible in the whole application source.

However, this is only desirable for items that I want to
reveal explicitly, of course. 
That is exactly why I need the *private* access modifier as it is now 
and not *fileprivate*  
So I am very glad that this access modifier *private* finally became 
available in Swift 3

In my classes, *private* is probably the most used keyword, but
*private* should be the default for entities within a class body
just like it is for entities within functions.

As far as I know, prefixing with *private* is the only solution in Swift to 
protect
functions, vars etc. in my class against unwanted access 
from the outer scope. I think this is not the way it should be. 

Making all entities in a class private prevents this.
and offers also reasonable protection against
the Fragile Base Class problem, (thanks Chris for url) :
 https://en.wikipedia.org/wiki/Fragile_base_class 


A solution for as it is now, albeit not a perfect one would be, 
to have some sort of access modifier which defines 
all items within the class to be private by default.
perhaps the keyword *closedscope* like in this example:

closedscope class TG3DGauge: SCNNode
{

var needles = [SCNNode]()  // is now private by default
var fmtStr = “"// is now private by default

public var value: CGFloat = 0 // Public!! visible outside class 
   // “fileprivate" or “internal”  can also be used.
{
didSet  // trigger value change, rotate needles etc.
{
valueChange()
}
}

var nodeUnitText = SCNNode()  // is now private by default
var nodeValueText = SCNNode() // is now private by default

//etc.


Again, for this reasons, don’t drop the distinction between
between *fileprivate* and *private* 
if this is done, there is afaics no way to protect items within a class body.
Leave it as it is now, please. (also to prevent source breaking as well)

(btw, the above TG3DGauge class is a perfect example: 
With real gauges it would not be a good idea if one can touch
the needles and gears inside the gauge’s casing,
which is exactly the case with OOP. e.g.
In my class example people would e.g. be able to set the angle
from needles (if not declared private)  directly, without updating the value.) 


TedvG
www.tedvg.com   (see my gauges from above class here)



>> Le 13 oct. 2016 à 07:52, Chris Lattner via swift-evolution 
>> > a écrit :
>> 
>> On Oct 12, 2016, at 9:56 PM, Russ Bishop via swift-evolution 
>>  
>> >> wrote:
> I actually consider it very lucky that most of our changes so far have 
> been fairly non-controversial. Everybody has a different idea of what 
> would make Swift a better language, and all of us well-meaning. But when 
> those ideas conflict, some group is going to end up unhappy. I'm actually 
> very glad that (a) we haven't had too many of these cases, and (b) even 
> when we have, people have been able to accept it and move on to 
> contributing to the next issue.
 
 
 Strong agreement here as well. This proposal has 

Re: [swift-evolution] private & fileprivate

[Kevin Ballard via swift-evolution]

On Sat, Oct 8, 2016, at 07:42 AM, Anton Zhilin via swift-evolution wrote:
> As far as I can see, almost all people, who talk here, agree that
> private / fileprivate distinction brought more harm than good. Despite
> corresponding proposal being accepted.
> I think, it means that current mailing-list system is failing. Let's
> accept it, gmane looks and feels ugly by comparison to forums. And
> using email limits the number of people involved by an order of
> magnitude.
> What we need is popularization of SE, reaching as many developers as
> we can, using simple voting, likes, and so on.

This is a bad conclusion. Discussions like this naturally attract people
who are unhappy with the status quo. So it's no surprise that you're
seeing a lot of people say they don't like private. Personally, I *love*
having the new private and I use it almost everywhere. It's very rare
for me to write fileprivate and when I do, it's an intentional decision.
And the only reason I even saw this thread is because someone linked it
to me on Slack.

-Kevin Ballard

> 2016-10-08 12:31 GMT+03:00 Haravikk via swift-evolution  evolut...@swift.org>:
>>
>> > On 7 Oct 2016, at 22:44, Tony Allevato via swift-evolution > > evolut...@swift.org> wrote:
>>  > personally I thought `private` was fine the way it was when it
>>  > meant `fileprivate` and I had no real need for `private` as it
>>  > exists in Swift 3.
>>
>> I have to agree with this; I wasn't especially comfortable with the
>> change (or the eventual choice of keyword style) and in practice I
>> just don't find it useful. I haven't used the new "private" even once
>> since it was added, except by accident, the only form of private I
>> use is fileprivate.
>>
>>  I've happily embraced the conform through extension style in Swift,
>>  and really when it comes down to it the new private access level
>>  just isn't compatible with that style of development. It's only
>>  really useful for hiding details of something you add in one
>>  specific section, which I almost never do (and when I do I just mark
>>  it fileprivate in case I can re-use it).
>>
>>  Maybe some people do find it useful, but I'd prefer fileprivate to
>>  be the default behaviour of private; the current (scoped?) private
>>  access level seems far more limited, thus more deserving of a less
>>  convenient keyword, or some kind of modifier on private. But
>>  personally I'd be fine with removing it, as I don't think it really
>>  adds anything that fileprivate doesn't already cover.
> _
> 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

Re: [swift-evolution] private & fileprivate

[David Hart via swift-evolution]

> On 13 Oct 2016, at 08:25, Jean-Daniel via swift-evolution 
>  wrote:
> 
> 
>> Le 13 oct. 2016 à 07:52, Chris Lattner via swift-evolution 
>> > a écrit :
>> 
>> On Oct 12, 2016, at 9:56 PM, Russ Bishop via swift-evolution 
>> > wrote:
> I actually consider it very lucky that most of our changes so far have 
> been fairly non-controversial. Everybody has a different idea of what 
> would make Swift a better language, and all of us well-meaning. But when 
> those ideas conflict, some group is going to end up unhappy. I'm actually 
> very glad that (a) we haven't had too many of these cases, and (b) even 
> when we have, people have been able to accept it and move on to 
> contributing to the next issue.
 
 
 Strong agreement here as well. This proposal has been litigated numerous 
 times already, and the bar for source-breaking changes is much higher now. 
 To effectively re-open the discussion would require a proposal that 
 significant changes the model with a lot of evidence that such a new model 
 is a drastic improvement over what we have now. “Back out SE-0025” is not 
 a viable option now.
 
- Doug
>>> 
>>> Not really. This proposal could be backed out without source-breaking 
>>> changes by treating private as a synonym for fileprivate and we’d have 
>>> Swift 2 behavior without breaking source. If the core team doesn’t want to 
>>> consider that then we can just move on and live with it. 
>> 
>> Not speaking for the core team, just MHO:
>> 
>> I agree with Russ here, and with others who have said upthread that the 
>> “thing that has changed” is that we are starting to get usage experience 
>> with fileprivate vs private.  I think we all understand the value of having 
>> fewer access control levels, and so if “private” isn’t conceptually pulling 
>> its weight, then it is reasonable to consider phasing it out.
>> 
>> That said, there is no specific rush to have this discussion, and I think it 
>> is reasonable to put a pretty high burden of proof on someone who wants to 
>> drive such a proposal.  For example, if we had the discussion in the spring 
>> timeframe, we should have a pretty large body of Swift 3 code readily at 
>> hand (e.g. SwiftPM packages and other various github repos).
>> 
>> Given that, it should be easy enough to see how widely private is actually 
>> being used in practice.  If it is very rare, then the argument to ditch it 
>> (make it a synonym for fileprivate, and eventually phasing out fileprivate) 
>> is strong.  If lots of people are using private and only some are using 
>> fileprivate, then the discussion is quite different.
>> 
>> -Chris
> 
> I don’t think monitoring the usage of private vs fileprivate is fair. By 
> default, people will use private until they encounter visibility issues and 
> discover they need to change to fileprivate. So private will probably being 
> use far more than fileprivate.
> Nonetheless it does not mean people chosen private because it effectively 
> reduce the visibility to the class scope, but just because it is easier to 
> discover and to type than fileprivate and fit in many cases.
> 
> I tend to write class will all ivars private by default (as it is a sensible 
> default), and then, when I start to write extensions and other parts, I have 
> to switch to fileprivate for a bunch of ivars. It create an inconsistent mess 
> in my ivars declaration as it is difficult to know if an ivar is private 
> because I has to be, or because I didn’t encounter a case that need it to be 
> fileprivate instead.
> 
> Honestly, I don’t see any value in the introduction of fileprivate.
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

I also agree that monitoring the usage of private vs fileprivate is not fair. I 
now use private heavily simply because I don’t want the burden of mixing 
private and fileprivate (and find the name of fileprivate slightly 
verbose/ugly). But that does not mean I would vote for keeping private. I would 
still vote for going back to Swift 2 behaviour. But I agree that we can wait 
until the summer to look at this again.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] private & fileprivate

[Chris Lattner via swift-evolution]

On Oct 12, 2016, at 9:56 PM, Russ Bishop via swift-evolution 
 wrote:
>>> I actually consider it very lucky that most of our changes so far have been 
>>> fairly non-controversial. Everybody has a different idea of what would make 
>>> Swift a better language, and all of us well-meaning. But when those ideas 
>>> conflict, some group is going to end up unhappy. I'm actually very glad 
>>> that (a) we haven't had too many of these cases, and (b) even when we have, 
>>> people have been able to accept it and move on to contributing to the next 
>>> issue.
>> 
>> 
>> Strong agreement here as well. This proposal has been litigated numerous 
>> times already, and the bar for source-breaking changes is much higher now. 
>> To effectively re-open the discussion would require a proposal that 
>> significant changes the model with a lot of evidence that such a new model 
>> is a drastic improvement over what we have now. “Back out SE-0025” is not a 
>> viable option now.
>> 
>>  - Doug
> 
> Not really. This proposal could be backed out without source-breaking changes 
> by treating private as a synonym for fileprivate and we’d have Swift 2 
> behavior without breaking source. If the core team doesn’t want to consider 
> that then we can just move on and live with it. 

Not speaking for the core team, just MHO:

I agree with Russ here, and with others who have said upthread that the “thing 
that has changed” is that we are starting to get usage experience with 
fileprivate vs private.  I think we all understand the value of having fewer 
access control levels, and so if “private” isn’t conceptually pulling its 
weight, then it is reasonable to consider phasing it out.

That said, there is no specific rush to have this discussion, and I think it is 
reasonable to put a pretty high burden of proof on someone who wants to drive 
such a proposal.  For example, if we had the discussion in the spring 
timeframe, we should have a pretty large body of Swift 3 code readily at hand 
(e.g. SwiftPM packages and other various github repos).

Given that, it should be easy enough to see how widely private is actually 
being used in practice.  If it is very rare, then the argument to ditch it 
(make it a synonym for fileprivate, and eventually phasing out fileprivate) is 
strong.  If lots of people are using private and only some are using 
fileprivate, then the discussion is quite different.

-Chris



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

Re: [swift-evolution] private & fileprivate

[Russ Bishop via swift-evolution]

> On Oct 10, 2016, at 9:59 AM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> 
>> On Oct 7, 2016, at 3:56 PM, Jordan Rose via swift-evolution 
>> > wrote:
>> 
>>> 
>>> On Oct 7, 2016, at 15:15, William Sumner via swift-evolution 
>>> > wrote:
>>> 
>>> 
 On Oct 7, 2016, at 3:05 PM, Zach Waldowski via swift-evolution 
 > wrote:
 
 I third this sentiment. fileprivate is a nice idea and very clearly has 
 its uses (which is why the proposal got traction in the first place), but 
 when combined with the other access levels, the language feature as a 
 whole feels arbitrary. In practical use, files that I felt were nicely 
 encapsulated and hiding implementation details are now a scattered mix of 
 access levels, adding cognitive load and making the code look unorganized 
 for having the gall to use extensions to split up functionality.
 
 Sincerely,
   Zachary Waldowski
   z...@waldowski.me 
>>> 
>>> Beyond the textual change of using a different modifier name, I don’t see 
>>> how the encapsulation and organization of code could be affected. Really, 
>>> there’s not much point in rehashing prior discussion of SE-0025 unless 
>>> there’s a previously unconsidered angle.
>> 
>> I strongly agree with this sentiment. SE-0025 was very heavily discussed, 
>> and while many people were not satisfied with the solution we went with 
>> (including me!), it was what the core team and community converged on. I 
>> don't expect us to change access control again until and unless we decide to 
>> change the model in some way, and even then I think we'll want to go through 
>> extra effort to maintain compatibility with Swift 3. As has been mentioned 
>> repeatedly, the bar for source-breaking changes is much higher than it was 
>> in the first few months of swift-evolution.
>> 
>> I actually consider it very lucky that most of our changes so far have been 
>> fairly non-controversial. Everybody has a different idea of what would make 
>> Swift a better language, and all of us well-meaning. But when those ideas 
>> conflict, some group is going to end up unhappy. I'm actually very glad that 
>> (a) we haven't had too many of these cases, and (b) even when we have, 
>> people have been able to accept it and move on to contributing to the next 
>> issue.
> 
> 
> Strong agreement here as well. This proposal has been litigated numerous 
> times already, and the bar for source-breaking changes is much higher now. To 
> effectively re-open the discussion would require a proposal that significant 
> changes the model with a lot of evidence that such a new model is a drastic 
> improvement over what we have now. “Back out SE-0025” is not a viable option 
> now.
> 
>   - Doug

Not really. This proposal could be backed out without source-breaking changes 
by treating private as a synonym for fileprivate and we’d have Swift 2 behavior 
without breaking source. If the core team doesn’t want to consider that then we 
can just move on and live with it. 

Everyone needs to disagree and commit at one time or another. It just irks me 
because it’s so ugly :)

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

Re: [swift-evolution] private & fileprivate

[Chris Lattner via swift-evolution]

On Oct 8, 2016, at 12:15 PM, Matthew Johnson via swift-evolution 
 wrote:
> 
> There are rather significant optimization barriers at module boundaries right 
> now.  These do not exist for the standard library due to its tight 
> relationship with the compiler, but for the moment it is a non-trivial 
> concern for 3rd party code that is performance sensitive.  This is 
> effectively a language pressure in the direction of larger modules, at least 
> for some domains.  (Hopefully this pressure will eventually be alleviated - 
> there has been at least some talk in that direction)

Indeed, I expect that this will be a big focus over the next year.  The 
resilience model and ABI stability drive the urgency of getting this worked out.

-Chris

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

Re: [swift-evolution] private & fileprivate

[Douglas Gregor via swift-evolution]

> On Oct 7, 2016, at 3:56 PM, Jordan Rose via swift-evolution 
>  wrote:
> 
>> 
>> On Oct 7, 2016, at 15:15, William Sumner via swift-evolution 
>> > wrote:
>> 
>> 
>>> On Oct 7, 2016, at 3:05 PM, Zach Waldowski via swift-evolution 
>>> > wrote:
>>> 
>>> I third this sentiment. fileprivate is a nice idea and very clearly has its 
>>> uses (which is why the proposal got traction in the first place), but when 
>>> combined with the other access levels, the language feature as a whole 
>>> feels arbitrary. In practical use, files that I felt were nicely 
>>> encapsulated and hiding implementation details are now a scattered mix of 
>>> access levels, adding cognitive load and making the code look unorganized 
>>> for having the gall to use extensions to split up functionality.
>>> 
>>> Sincerely,
>>>   Zachary Waldowski
>>>   z...@waldowski.me 
>> 
>> Beyond the textual change of using a different modifier name, I don’t see 
>> how the encapsulation and organization of code could be affected. Really, 
>> there’s not much point in rehashing prior discussion of SE-0025 unless 
>> there’s a previously unconsidered angle.
> 
> I strongly agree with this sentiment. SE-0025 was very heavily discussed, and 
> while many people were not satisfied with the solution we went with 
> (including me!), it was what the core team and community converged on. I 
> don't expect us to change access control again until and unless we decide to 
> change the model in some way, and even then I think we'll want to go through 
> extra effort to maintain compatibility with Swift 3. As has been mentioned 
> repeatedly, the bar for source-breaking changes is much higher than it was in 
> the first few months of swift-evolution.
> 
> I actually consider it very lucky that most of our changes so far have been 
> fairly non-controversial. Everybody has a different idea of what would make 
> Swift a better language, and all of us well-meaning. But when those ideas 
> conflict, some group is going to end up unhappy. I'm actually very glad that 
> (a) we haven't had too many of these cases, and (b) even when we have, people 
> have been able to accept it and move on to contributing to the next issue.


Strong agreement here as well. This proposal has been litigated numerous times 
already, and the bar for source-breaking changes is much higher now. To 
effectively re-open the discussion would require a proposal that significant 
changes the model with a lot of evidence that such a new model is a drastic 
improvement over what we have now. “Back out SE-0025” is not a viable option 
now.

- Doug

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

Re: [swift-evolution] private & fileprivate

[Xiaodi Wu via swift-evolution]

I don't find this example persuasive, because:

1125 LOC is on the long side for a single file, but not by any means
"thousands" of LOC.

In any case, having hacked on corelibs-foundation myself, my sense is that
its files are organized in such a way that NSDecimal would be expected to
be implemented in a single file regardless of length.

If Swift had submodules, there's no reason to say that Foundation wouldn't
make use of them to organize its types.

Even if you wished to share implementation details between, say, a
hypothetically split up NSDecimal and Decimal, fileprivate members of
NSDecimal could simply be internal instead, as is done elsewhere in
corelibs-foundation. Note by comparison that, for implementation reasons,
stdlib doesn't use fileprivate scope and all implementation details are
internal or even public and underscored. A compelling argument for more
fine-grained controls here would demonstrate how internal scope in stdlib
or corelibs-foundation actually led to a bug that could have been
prevented--I don't think any such bug exists.
On Mon, Oct 10, 2016 at 04:30 Alex Blewitt  wrote:

>
> On 8 Oct 2016, at 20:01, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Sat, Oct 8, 2016 at 12:02 PM, Karl via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On 8 Oct 2016, at 16:47, Braeden Profile  wrote:
>
>
> On Oct 8, 2016, at 6:58 AM, Karl via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I was thinking that the domains themselves could be associated with a
> domain, so you could create alternate domains which are also
> publicly-visible, but distinct from the default, “public” domain.
>
> For example, if you have a bunch of methods which should be visible to
> subclasses, but you don’t want them to clutter your regular interface.
> Perhaps they have names which are confusingly-similar to the public API. I
> believe that is what “protected” is typically used for.
>
>
> Yes, but “protected" was specifically put down by the core team, seeing
> that any code from outside the library should see the class as one
> well-designed whole, not something with complicated, visible implementation
> details.  If your class-internal methods are confusing (and aren’t
> necessary for normal use), they shouldn’t be made public in any way.
> Subclasses would too easily confuse the distinction between your
> implementation methods and your public ones.
>
> For what it’s worth, I was only confused by “private” and “fileprivate”
> for a minute or two until I looked up the actual proposal.  I haven’t had
> trouble with it, and it does actually provide more flexibility for code
> access at the file level than we had before.  Even if the syntax is clunky.
>
>
> I’m not saying that (file)private is confusing - it’s very clear about
> what it does. But it is limiting; anything that wants access to those
> semi-private details needs to live in the same file. That’s clearly not
> scalable. Enormous files many thousands of lines long are easy for the
> compiler to digest, but less easy for humans to understand and navigate. In
> fact, I believe this whole “file-based” access control originally came out
> of the compiler’s implementation details.
>
>
> I'm interested in more information about this. What sorts of code have you
> been writing where a file would have to be thousands of lines long in order
> to accommodate `fileprivate`? Many entire modules are only thousands of
> lines long--is there a reason this code couldn't be refactored into a
> module of its own? As mentioned by Matthew, isn't this calling for some
> notion of submodules?
>
>
> I'm implementing NSDecimal in Swift and it uses fileprivate to wrap up
> scope for internal implementation details. The implementation that I've got
> on my GitHub account is currently at 885 lines; but I'm still working on
> other parts and my currently checked out version has 1125 lines of code, in
> a single file.
>
>
> https://github.com/alblue/swift-corelibs-foundation/blob/nsdecimal/Foundation/NSDecimal.swift
>
> Submodules aren't the right answer here, because Foundation as a while is
> a module that won't be split apart. And for performance reasons, you want
> the internal functions (defined fileprivate) to be considered as eligible
> for optimisation by the compiler in the absence of (say) whole module
> optimisation.
>
> Right now, the only way to do that is to have the fiileprivate
> implementations in the same file as the rest of the implementation.
>
> Alex
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] private & fileprivate

[Alex Blewitt via swift-evolution]

> On 8 Oct 2016, at 20:01, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> On Sat, Oct 8, 2016 at 12:02 PM, Karl via swift-evolution 
> > wrote:
> 
>> On 8 Oct 2016, at 16:47, Braeden Profile > > wrote:
>> 
>>> 
>>> On Oct 8, 2016, at 6:58 AM, Karl via swift-evolution 
>>> > wrote:
>>> 
>>> I was thinking that the domains themselves could be associated with a 
>>> domain, so you could create alternate domains which are also 
>>> publicly-visible, but distinct from the default, “public” domain.
>>> 
>>> For example, if you have a bunch of methods which should be visible to 
>>> subclasses, but you don’t want them to clutter your regular interface. 
>>> Perhaps they have names which are confusingly-similar to the public API. I 
>>> believe that is what “protected” is typically used for.
>> 
>> Yes, but “protected" was specifically put down by the core team, seeing that 
>> any code from outside the library should see the class as one well-designed 
>> whole, not something with complicated, visible implementation details.  If 
>> your class-internal methods are confusing (and aren’t necessary for normal 
>> use), they shouldn’t be made public in any way.  Subclasses would too easily 
>> confuse the distinction between your implementation methods and your public 
>> ones.
>> 
>> For what it’s worth, I was only confused by “private” and “fileprivate” for 
>> a minute or two until I looked up the actual proposal.  I haven’t had 
>> trouble with it, and it does actually provide more flexibility for code 
>> access at the file level than we had before.  Even if the syntax is clunky.
> 
> I’m not saying that (file)private is confusing - it’s very clear about what 
> it does. But it is limiting; anything that wants access to those semi-private 
> details needs to live in the same file. That’s clearly not scalable. Enormous 
> files many thousands of lines long are easy for the compiler to digest, but 
> less easy for humans to understand and navigate. In fact, I believe this 
> whole “file-based” access control originally came out of the compiler’s 
> implementation details.
> 
> I'm interested in more information about this. What sorts of code have you 
> been writing where a file would have to be thousands of lines long in order 
> to accommodate `fileprivate`? Many entire modules are only thousands of lines 
> long--is there a reason this code couldn't be refactored into a module of its 
> own? As mentioned by Matthew, isn't this calling for some notion of 
> submodules?

I'm implementing NSDecimal in Swift and it uses fileprivate to wrap up scope 
for internal implementation details. The implementation that I've got on my 
GitHub account is currently at 885 lines; but I'm still working on other parts 
and my currently checked out version has 1125 lines of code, in a single file.

https://github.com/alblue/swift-corelibs-foundation/blob/nsdecimal/Foundation/NSDecimal.swift
 


Submodules aren't the right answer here, because Foundation as a while is a 
module that won't be split apart. And for performance reasons, you want the 
internal functions (defined fileprivate) to be considered as eligible for 
optimisation by the compiler in the absence of (say) whole module optimisation.

Right now, the only way to do that is to have the fiileprivate implementations 
in the same file as the rest of the implementation.

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

Re: [swift-evolution] private & fileprivate

[Rien via swift-evolution]

> On 09 Oct 2016, at 19:22, Daniel Tartaglia via swift-evolution 
>  wrote:
> 
> the programer specifies exactly which methods can be used by which classes.

That IMO is the only sensible solution. Everything else -even in the name of 
simplicity- will be insufficient and complicate matters.


> So a “public” method would be defined as accessible to “[Any]” and a private 
> method would be defined as accessible to “[Self]”. If you want to grant 
> access of a particular method to only particular helper classes, you would 
> specify them.
> 
> Having a system like that would solve Karl’s problem because it wouldn’t 
> matter what physical file the classes are in. 
> ___
> 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

Re: [swift-evolution] private & fileprivate

[Trans via swift-evolution]

That sounds absolutely horrible. Keep building walls and ultimately you'll
never leave your bike shed.

On Oct 9, 2016 1:23 PM, "Daniel Tartaglia via swift-evolution" <
swift-evolution@swift.org> wrote:

> This discussion reminds me of Eiffel’s access system. Instead of having
> these generic “public/private” distinctions, in Eiffel the programer
> specifies exactly which methods can be used by which classes. So a “public”
> method would be defined as accessible to “[Any]” and a private method would
> be defined as accessible to “[Self]”. If you want to grant access of a
> particular method to only particular helper classes, you would specify them.
>
> Having a system like that would solve Karl’s problem because it wouldn’t
> matter what physical file the classes are in.
> ___
> 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

Re: [swift-evolution] private & fileprivate

[Daniel Tartaglia via swift-evolution]

This discussion reminds me of Eiffel’s access system. Instead of having these 
generic “public/private” distinctions, in Eiffel the programer specifies 
exactly which methods can be used by which classes. So a “public” method would 
be defined as accessible to “[Any]” and a private method would be defined as 
accessible to “[Self]”. If you want to grant access of a particular method to 
only particular helper classes, you would specify them.

Having a system like that would solve Karl’s problem because it wouldn’t matter 
what physical file the classes are in. 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] private & fileprivate

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Oct 8, 2016, at 5:58 PM, Xiaodi Wu  wrote:
> 
> Very much agree with essentially all of that.
> 
> Personally, I'd also want to explore whether any submodule scope could just 
> subsume fileprivate (i.e., files not otherwise in a submodule behave as 
> though they are their own submodule for access control purposes) rather than 
> occupy another slot between it and internal, but that's a discussion we can 
> postpone until a submodule proposal takes shape.
> 

That's an interesting thought.  Files are such a concrete unit of scope that I 
think I would still prefer to see the file level access control as well, but 
I'm open to seeing specifics of other ideas when the time is right (which afaik 
is not Swift 4 phase 1).

>> On Sat, Oct 8, 2016 at 17:27 Matthew Johnson  wrote:
>> 
>> 
>> Sent from my iPad
>> 
>>> On Oct 8, 2016, at 3:24 PM, Xiaodi Wu  wrote:
>>> 
 On Sat, Oct 8, 2016 at 2:15 PM, Matthew Johnson  
 wrote:
 
 On Oct 8, 2016, at 2:01 PM, Xiaodi Wu via swift-evolution 
  wrote:
 
> On Sat, Oct 8, 2016 at 12:02 PM, Karl via swift-evolution 
>  wrote:
> 
>> On 8 Oct 2016, at 16:47, Braeden Profile  wrote:
>> 
>> 
>> On Oct 8, 2016, at 6:58 AM, Karl via swift-evolution 
>>  wrote:
>> 
>> I was thinking that the domains themselves could be associated with a 
>> domain, so you could create alternate domains which are also 
>> publicly-visible, but distinct from the default, “public” domain.
>> 
>> For example, if you have a bunch of methods which should be visible to 
>> subclasses, but you don’t want them to clutter your regular interface. 
>> Perhaps they have names which are confusingly-similar to the public API. 
>> I believe that is what “protected” is typically used for.
> 
> Yes, but “protected" was specifically put down by the core team, seeing 
> that any code from outside the library should see the class as one 
> well-designed whole, not something with complicated, visible 
> implementation details.  If your class-internal methods are confusing 
> (and aren’t necessary for normal use), they shouldn’t be made public in 
> any way.  Subclasses would too easily confuse the distinction between 
> your implementation methods and your public ones.
> 
> For what it’s worth, I was only confused by “private” and “fileprivate” 
> for a minute or two until I looked up the actual proposal.  I haven’t had 
> trouble with it, and it does actually provide more flexibility for code 
> access at the file level than we had before.  Even if the syntax is 
> clunky.
 
 I’m not saying that (file)private is confusing - it’s very clear about 
 what it does. But it is limiting; anything that wants access to those 
 semi-private details needs to live in the same file. That’s clearly not 
 scalable. Enormous files many thousands of lines long are easy for the 
 compiler to digest, but less easy for humans to understand and navigate. 
 In fact, I believe this whole “file-based” access control originally came 
 out of the compiler’s implementation details.
 
 I'm interested in more information about this. What sorts of code have you 
 been writing where a file would have to be thousands of lines long in 
 order to accommodate `fileprivate`? Many entire modules are only thousands 
 of lines long--is there a reason this code couldn't be refactored into a 
 module of its own? As mentioned by Matthew, isn't this calling for some 
 notion of submodules?
>>> 
>>> There are rather significant optimization barriers at module boundaries 
>>> right now.  These do not exist for the standard library due to its tight 
>>> relationship with the compiler, but for the moment it is a non-trivial 
>>> concern for 3rd party code that is performance sensitive.  This is 
>>> effectively a language pressure in the direction of larger modules, at 
>>> least for some domains.  (Hopefully this pressure will eventually be 
>>> alleviated - there has been at least some talk in that direction)
>>> 
>>> Great point. IMO, it'd be important to identify how much of the desire for 
>>> additional varieties of access modifiers represent workarounds to compiler 
>>> limitations, because we'd be better off making optimization across module 
>>> boundaries work better if that's the root of the issue. Certainly, also, 
>>> submodules are a discussion that, having made a brief appearance at the end 
>>> of Swift 3 evolution, would be ripe for Swift 4 phase 2.
>>> 
>>> As for this topic about additional access modifiers, I'd like to understand 
>>> what current use cases motivate them that arise because the current syntax 
>>> is 

Re: [swift-evolution] private & fileprivate

[Xiaodi Wu via swift-evolution]

Very much agree with essentially all of that.

Personally, I'd also want to explore whether any submodule scope could just
subsume fileprivate (i.e., files not otherwise in a submodule behave as
though they are their own submodule for access control purposes) rather
than occupy another slot between it and internal, but that's a discussion
we can postpone until a submodule proposal takes shape.

On Sat, Oct 8, 2016 at 17:27 Matthew Johnson  wrote:

>
>
> Sent from my iPad
>
> On Oct 8, 2016, at 3:24 PM, Xiaodi Wu  wrote:
>
> On Sat, Oct 8, 2016 at 2:15 PM, Matthew Johnson 
> wrote:
>
>
> On Oct 8, 2016, at 2:01 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Sat, Oct 8, 2016 at 12:02 PM, Karl via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On 8 Oct 2016, at 16:47, Braeden Profile  wrote:
>
>
> On Oct 8, 2016, at 6:58 AM, Karl via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I was thinking that the domains themselves could be associated with a
> domain, so you could create alternate domains which are also
> publicly-visible, but distinct from the default, “public” domain.
>
> For example, if you have a bunch of methods which should be visible to
> subclasses, but you don’t want them to clutter your regular interface.
> Perhaps they have names which are confusingly-similar to the public API. I
> believe that is what “protected” is typically used for.
>
>
> Yes, but “protected" was specifically put down by the core team, seeing
> that any code from outside the library should see the class as one
> well-designed whole, not something with complicated, visible implementation
> details.  If your class-internal methods are confusing (and aren’t
> necessary for normal use), they shouldn’t be made public in any way.
> Subclasses would too easily confuse the distinction between your
> implementation methods and your public ones.
>
> For what it’s worth, I was only confused by “private” and “fileprivate”
> for a minute or two until I looked up the actual proposal.  I haven’t had
> trouble with it, and it does actually provide more flexibility for code
> access at the file level than we had before.  Even if the syntax is clunky.
>
>
> I’m not saying that (file)private is confusing - it’s very clear about
> what it does. But it is limiting; anything that wants access to those
> semi-private details needs to live in the same file. That’s clearly not
> scalable. Enormous files many thousands of lines long are easy for the
> compiler to digest, but less easy for humans to understand and navigate. In
> fact, I believe this whole “file-based” access control originally came out
> of the compiler’s implementation details.
>
>
> I'm interested in more information about this. What sorts of code have you
> been writing where a file would have to be thousands of lines long in order
> to accommodate `fileprivate`? Many entire modules are only thousands of
> lines long--is there a reason this code couldn't be refactored into a
> module of its own? As mentioned by Matthew, isn't this calling for some
> notion of submodules?
>
>
> There are rather significant optimization barriers at module boundaries
> right now.  These do not exist for the standard library due to its tight
> relationship with the compiler, but for the moment it is a non-trivial
> concern for 3rd party code that is performance sensitive.  This is
> effectively a language pressure in the direction of larger modules, at
> least for some domains.  (Hopefully this pressure will eventually be
> alleviated - there has been at least some talk in that direction)
>
>
> Great point. IMO, it'd be important to identify how much of the desire for
> additional varieties of access modifiers represent workarounds to compiler
> limitations, because we'd be better off making optimization across module
> boundaries work better if that's the root of the issue. Certainly, also,
> submodules are a discussion that, having made a brief appearance at the end
> of Swift 3 evolution, would be ripe for Swift 4 phase 2.
>
> As for this topic about additional access modifiers, I'd like to
> understand what current use cases motivate them that arise because the
> current syntax is insufficiently expressive, rather than compiler
> shortcomings or the lack of other features that are on the horizon. The
> latter sorts of motivation, IMO, would be more definitively addressed by
> tackling the root problem; adding additional syntax in order to work around
> compiler limitations seems as best inelegant.
>
>
> I agree completely.  We definitely don't want to add features motivated
> only by current limitations.
>
> IMO there is plenty of motivation for submodules from a number of
> different angles.  If we do add them I think allowing an access control
> distinction between submodule and whole module makes a lot of sense.   That
> isn't sufficient 

Re: [swift-evolution] private & fileprivate

[Xiaodi Wu via swift-evolution]

On Sat, Oct 8, 2016 at 3:24 PM, Karl  wrote:

>
> On 8 Oct 2016, at 21:01, Xiaodi Wu  wrote:
>
> On Sat, Oct 8, 2016 at 12:02 PM, Karl via swift-evolution  evolut...@swift.org> wrote:
>
>>
>> On 8 Oct 2016, at 16:47, Braeden Profile  wrote:
>>
>>
>> On Oct 8, 2016, at 6:58 AM, Karl via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> I was thinking that the domains themselves could be associated with a
>> domain, so you could create alternate domains which are also
>> publicly-visible, but distinct from the default, “public” domain.
>>
>> For example, if you have a bunch of methods which should be visible to
>> subclasses, but you don’t want them to clutter your regular interface.
>> Perhaps they have names which are confusingly-similar to the public API. I
>> believe that is what “protected” is typically used for.
>>
>>
>> Yes, but “protected" was specifically put down by the core team, seeing
>> that any code from outside the library should see the class as one
>> well-designed whole, not something with complicated, visible implementation
>> details.  If your class-internal methods are confusing (and aren’t
>> necessary for normal use), they shouldn’t be made public in any way.
>> Subclasses would too easily confuse the distinction between your
>> implementation methods and your public ones.
>>
>> For what it’s worth, I was only confused by “private” and “fileprivate”
>> for a minute or two until I looked up the actual proposal.  I haven’t had
>> trouble with it, and it does actually provide more flexibility for code
>> access at the file level than we had before.  Even if the syntax is clunky.
>>
>>
>> I’m not saying that (file)private is confusing - it’s very clear about
>> what it does. But it is limiting; anything that wants access to those
>> semi-private details needs to live in the same file. That’s clearly not
>> scalable. Enormous files many thousands of lines long are easy for the
>> compiler to digest, but less easy for humans to understand and navigate. In
>> fact, I believe this whole “file-based” access control originally came out
>> of the compiler’s implementation details.
>>
>
> I'm interested in more information about this. What sorts of code have you
> been writing where a file would have to be thousands of lines long in order
> to accommodate `fileprivate`? Many entire modules are only thousands of
> lines long--is there a reason this code couldn't be refactored into a
> module of its own? As mentioned by Matthew, isn't this calling for some
> notion of submodules?
>
>
> The tab controller was one example:
>
> - final class TabController : UIViewController
> - final class TabControllerView : UIView
> - final class Tab : UIView
>
> All of these required knowledge of semi-private implementation details of
> each-other due to the API I wanted to achieve. I wasn’t interested in
> factoring out the interfaces in to protocols because they’re all final
> classes and only supposed to be used with each other. For example,
> Tab.close() called a fileprivate function in TabController to actually
> close the tab given an instance of the underlying TabItem data structure.
>

That's interesting. And if you put all the uses of `fileprivate` members of
TabController in the same file, that file would be thousands of lines long?
Have you explored options where you nest types (e.g. `TabController.View`,
which would be able to access private members of `TabController`?)

In that case, submodules wouldn’t really help. I could technically define
> the TabController as a submodule and use “internal”, but that’s also much
> less than optimal. I want to expose a handful of functions to a handful of
> other types (and not expose those functions anywhere else - e.g. from my
> module-internal UIViewControllers which happen to contain a TabController).
> Also, how would I expose things from the TabController module to the outer
> module without making it fully "public”?
>

If you want to expose only a handful of functions to a handful of other
types, it sounds like that would be a good use case for `fileprivate` that
would result in a very readable file, no?

> What it would basically come down to is that the interface of the object
>> would be separated in to blocks based on your access privileges. When
>> viewing the interface, it wouldn’t look much different to an extension:
>>
>> *access(public)* class TabController {
>>var tabs : [Tab] { get }
>>func closeTab(at: Int)
>> }
>>
>> *access(TabBarStuff)* extension TabController {
>> func close(tab: Tab)
>> }
>>
>> I definitely want something between internal and fileprivate, at least. I
>> don’t see any reason at all why objects shouldn’t be allowed to present
>> optional “slices” of their interface to appropriate clients. In fact, that
>> is what access control is all about. I just want to generalise it to allow
>> for user-defined visibility scopes (as well as the default 

Re: [swift-evolution] private & fileprivate

[Xiaodi Wu via swift-evolution]

On Sat, Oct 8, 2016 at 2:15 PM, Matthew Johnson 
wrote:

>
> On Oct 8, 2016, at 2:01 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Sat, Oct 8, 2016 at 12:02 PM, Karl via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> On 8 Oct 2016, at 16:47, Braeden Profile  wrote:
>>
>>
>> On Oct 8, 2016, at 6:58 AM, Karl via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> I was thinking that the domains themselves could be associated with a
>> domain, so you could create alternate domains which are also
>> publicly-visible, but distinct from the default, “public” domain.
>>
>> For example, if you have a bunch of methods which should be visible to
>> subclasses, but you don’t want them to clutter your regular interface.
>> Perhaps they have names which are confusingly-similar to the public API. I
>> believe that is what “protected” is typically used for.
>>
>>
>> Yes, but “protected" was specifically put down by the core team, seeing
>> that any code from outside the library should see the class as one
>> well-designed whole, not something with complicated, visible implementation
>> details.  If your class-internal methods are confusing (and aren’t
>> necessary for normal use), they shouldn’t be made public in any way.
>> Subclasses would too easily confuse the distinction between your
>> implementation methods and your public ones.
>>
>> For what it’s worth, I was only confused by “private” and “fileprivate”
>> for a minute or two until I looked up the actual proposal.  I haven’t had
>> trouble with it, and it does actually provide more flexibility for code
>> access at the file level than we had before.  Even if the syntax is clunky.
>>
>>
>> I’m not saying that (file)private is confusing - it’s very clear about
>> what it does. But it is limiting; anything that wants access to those
>> semi-private details needs to live in the same file. That’s clearly not
>> scalable. Enormous files many thousands of lines long are easy for the
>> compiler to digest, but less easy for humans to understand and navigate. In
>> fact, I believe this whole “file-based” access control originally came out
>> of the compiler’s implementation details.
>>
>
> I'm interested in more information about this. What sorts of code have you
> been writing where a file would have to be thousands of lines long in order
> to accommodate `fileprivate`? Many entire modules are only thousands of
> lines long--is there a reason this code couldn't be refactored into a
> module of its own? As mentioned by Matthew, isn't this calling for some
> notion of submodules?
>
>
> There are rather significant optimization barriers at module boundaries
> right now.  These do not exist for the standard library due to its tight
> relationship with the compiler, but for the moment it is a non-trivial
> concern for 3rd party code that is performance sensitive.  This is
> effectively a language pressure in the direction of larger modules, at
> least for some domains.  (Hopefully this pressure will eventually be
> alleviated - there has been at least some talk in that direction)
>

Great point. IMO, it'd be important to identify how much of the desire for
additional varieties of access modifiers represent workarounds to compiler
limitations, because we'd be better off making optimization across module
boundaries work better if that's the root of the issue. Certainly, also,
submodules are a discussion that, having made a brief appearance at the end
of Swift 3 evolution, would be ripe for Swift 4 phase 2.

As for this topic about additional access modifiers, I'd like to understand
what current use cases motivate them that arise because the current syntax
is insufficiently expressive, rather than compiler shortcomings or the lack
of other features that are on the horizon. The latter sorts of motivation,
IMO, would be more definitively addressed by tackling the root problem;
adding additional syntax in order to work around compiler limitations seems
as best inelegant.


> What it would basically come down to is that the interface of the object
>> would be separated in to blocks based on your access privileges. When
>> viewing the interface, it wouldn’t look much different to an extension:
>>
>> *access(public)* class TabController {
>>var tabs : [Tab] { get }
>>func closeTab(at: Int)
>> }
>>
>> *access(TabBarStuff)* extension TabController {
>> func close(tab: Tab)
>> }
>>
>> I definitely want something between internal and fileprivate, at least. I
>> don’t see any reason at all why objects shouldn’t be allowed to present
>> optional “slices” of their interface to appropriate clients. In fact, that
>> is what access control is all about. I just want to generalise it to allow
>> for user-defined visibility scopes (as well as the default ones for public,
>> module, file and scope). That leads to the question of what visibility
>> those user-defined scopes would 

Re: [swift-evolution] private & fileprivate

[Karl via swift-evolution]

> On 8 Oct 2016, at 21:01, Xiaodi Wu  wrote:
> 
> On Sat, Oct 8, 2016 at 12:02 PM, Karl via swift-evolution 
> > wrote:
> 
>> On 8 Oct 2016, at 16:47, Braeden Profile > > wrote:
>> 
>>> 
>>> On Oct 8, 2016, at 6:58 AM, Karl via swift-evolution 
>>> > wrote:
>>> 
>>> I was thinking that the domains themselves could be associated with a 
>>> domain, so you could create alternate domains which are also 
>>> publicly-visible, but distinct from the default, “public” domain.
>>> 
>>> For example, if you have a bunch of methods which should be visible to 
>>> subclasses, but you don’t want them to clutter your regular interface. 
>>> Perhaps they have names which are confusingly-similar to the public API. I 
>>> believe that is what “protected” is typically used for.
>> 
>> Yes, but “protected" was specifically put down by the core team, seeing that 
>> any code from outside the library should see the class as one well-designed 
>> whole, not something with complicated, visible implementation details.  If 
>> your class-internal methods are confusing (and aren’t necessary for normal 
>> use), they shouldn’t be made public in any way.  Subclasses would too easily 
>> confuse the distinction between your implementation methods and your public 
>> ones.
>> 
>> For what it’s worth, I was only confused by “private” and “fileprivate” for 
>> a minute or two until I looked up the actual proposal.  I haven’t had 
>> trouble with it, and it does actually provide more flexibility for code 
>> access at the file level than we had before.  Even if the syntax is clunky.
> 
> I’m not saying that (file)private is confusing - it’s very clear about what 
> it does. But it is limiting; anything that wants access to those semi-private 
> details needs to live in the same file. That’s clearly not scalable. Enormous 
> files many thousands of lines long are easy for the compiler to digest, but 
> less easy for humans to understand and navigate. In fact, I believe this 
> whole “file-based” access control originally came out of the compiler’s 
> implementation details.
> 
> I'm interested in more information about this. What sorts of code have you 
> been writing where a file would have to be thousands of lines long in order 
> to accommodate `fileprivate`? Many entire modules are only thousands of lines 
> long--is there a reason this code couldn't be refactored into a module of its 
> own? As mentioned by Matthew, isn't this calling for some notion of 
> submodules?
> 

The tab controller was one example:

- final class TabController : UIViewController
- final class TabControllerView : UIView
- final class Tab : UIView

All of these required knowledge of semi-private implementation details of 
each-other due to the API I wanted to achieve. I wasn’t interested in factoring 
out the interfaces in to protocols because they’re all final classes and only 
supposed to be used with each other. For example, Tab.close() called a 
fileprivate function in TabController to actually close the tab given an 
instance of the underlying TabItem data structure.

In that case, submodules wouldn’t really help. I could technically define the 
TabController as a submodule and use “internal”, but that’s also much less than 
optimal. I want to expose a handful of functions to a handful of other types 
(and not expose those functions anywhere else - e.g. from my module-internal 
UIViewControllers which happen to contain a TabController). Also, how would I 
expose things from the TabController module to the outer module without making 
it fully "public”?



> What it would basically come down to is that the interface of the object 
> would be separated in to blocks based on your access privileges. When viewing 
> the interface, it wouldn’t look much different to an extension:
> 
> access(public) class TabController {
>var tabs : [Tab] { get }
>func closeTab(at: Int)
> }
> 
> access(TabBarStuff) extension TabController {
> func close(tab: Tab)
> }
> 
> I definitely want something between internal and fileprivate, at least. I 
> don’t see any reason at all why objects shouldn’t be allowed to present 
> optional “slices” of their interface to appropriate clients. In fact, that is 
> what access control is all about. I just want to generalise it to allow for 
> user-defined visibility scopes (as well as the default ones for public, 
> module, file and scope). That leads to the question of what visibility those 
> user-defined scopes would have; and if you leave them entirely open to adopt 
> any scope (except themselves), then you end up with the ability to slice your 
> API for different use-cases. Or we could be boring and limit them to the 
> module they are defined in.
> 
> The whole reason I’m bringing this up is because I don’t like the “file” part 

Re: [swift-evolution] private & fileprivate

[Matthew Johnson via swift-evolution]

> On Oct 8, 2016, at 2:01 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> On Sat, Oct 8, 2016 at 12:02 PM, Karl via swift-evolution 
> > wrote:
> 
>> On 8 Oct 2016, at 16:47, Braeden Profile > > wrote:
>> 
>>> 
>>> On Oct 8, 2016, at 6:58 AM, Karl via swift-evolution 
>>> > wrote:
>>> 
>>> I was thinking that the domains themselves could be associated with a 
>>> domain, so you could create alternate domains which are also 
>>> publicly-visible, but distinct from the default, “public” domain.
>>> 
>>> For example, if you have a bunch of methods which should be visible to 
>>> subclasses, but you don’t want them to clutter your regular interface. 
>>> Perhaps they have names which are confusingly-similar to the public API. I 
>>> believe that is what “protected” is typically used for.
>> 
>> Yes, but “protected" was specifically put down by the core team, seeing that 
>> any code from outside the library should see the class as one well-designed 
>> whole, not something with complicated, visible implementation details.  If 
>> your class-internal methods are confusing (and aren’t necessary for normal 
>> use), they shouldn’t be made public in any way.  Subclasses would too easily 
>> confuse the distinction between your implementation methods and your public 
>> ones.
>> 
>> For what it’s worth, I was only confused by “private” and “fileprivate” for 
>> a minute or two until I looked up the actual proposal.  I haven’t had 
>> trouble with it, and it does actually provide more flexibility for code 
>> access at the file level than we had before.  Even if the syntax is clunky.
> 
> I’m not saying that (file)private is confusing - it’s very clear about what 
> it does. But it is limiting; anything that wants access to those semi-private 
> details needs to live in the same file. That’s clearly not scalable. Enormous 
> files many thousands of lines long are easy for the compiler to digest, but 
> less easy for humans to understand and navigate. In fact, I believe this 
> whole “file-based” access control originally came out of the compiler’s 
> implementation details.
> 
> I'm interested in more information about this. What sorts of code have you 
> been writing where a file would have to be thousands of lines long in order 
> to accommodate `fileprivate`? Many entire modules are only thousands of lines 
> long--is there a reason this code couldn't be refactored into a module of its 
> own? As mentioned by Matthew, isn't this calling for some notion of 
> submodules?

There are rather significant optimization barriers at module boundaries right 
now.  These do not exist for the standard library due to its tight relationship 
with the compiler, but for the moment it is a non-trivial concern for 3rd party 
code that is performance sensitive.  This is effectively a language pressure in 
the direction of larger modules, at least for some domains.  (Hopefully this 
pressure will eventually be alleviated - there has been at least some talk in 
that direction)

> 
> What it would basically come down to is that the interface of the object 
> would be separated in to blocks based on your access privileges. When viewing 
> the interface, it wouldn’t look much different to an extension:
> 
> access(public) class TabController {
>var tabs : [Tab] { get }
>func closeTab(at: Int)
> }
> 
> access(TabBarStuff) extension TabController {
> func close(tab: Tab)
> }
> 
> I definitely want something between internal and fileprivate, at least. I 
> don’t see any reason at all why objects shouldn’t be allowed to present 
> optional “slices” of their interface to appropriate clients. In fact, that is 
> what access control is all about. I just want to generalise it to allow for 
> user-defined visibility scopes (as well as the default ones for public, 
> module, file and scope). That leads to the question of what visibility those 
> user-defined scopes would have; and if you leave them entirely open to adopt 
> any scope (except themselves), then you end up with the ability to slice your 
> API for different use-cases. Or we could be boring and limit them to the 
> module they are defined in.
> 
> The whole reason I’m bringing this up is because I don’t like the “file” part 
> of fileprivate. How I split my files up is a readability decision.
> 
> Karl
> 
> ___
> 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

Re: [swift-evolution] private & fileprivate

[Xiaodi Wu via swift-evolution]

On Sat, Oct 8, 2016 at 12:02 PM, Karl via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On 8 Oct 2016, at 16:47, Braeden Profile  wrote:
>
>
> On Oct 8, 2016, at 6:58 AM, Karl via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I was thinking that the domains themselves could be associated with a
> domain, so you could create alternate domains which are also
> publicly-visible, but distinct from the default, “public” domain.
>
> For example, if you have a bunch of methods which should be visible to
> subclasses, but you don’t want them to clutter your regular interface.
> Perhaps they have names which are confusingly-similar to the public API. I
> believe that is what “protected” is typically used for.
>
>
> Yes, but “protected" was specifically put down by the core team, seeing
> that any code from outside the library should see the class as one
> well-designed whole, not something with complicated, visible implementation
> details.  If your class-internal methods are confusing (and aren’t
> necessary for normal use), they shouldn’t be made public in any way.
> Subclasses would too easily confuse the distinction between your
> implementation methods and your public ones.
>
> For what it’s worth, I was only confused by “private” and “fileprivate”
> for a minute or two until I looked up the actual proposal.  I haven’t had
> trouble with it, and it does actually provide more flexibility for code
> access at the file level than we had before.  Even if the syntax is clunky.
>
>
> I’m not saying that (file)private is confusing - it’s very clear about
> what it does. But it is limiting; anything that wants access to those
> semi-private details needs to live in the same file. That’s clearly not
> scalable. Enormous files many thousands of lines long are easy for the
> compiler to digest, but less easy for humans to understand and navigate. In
> fact, I believe this whole “file-based” access control originally came out
> of the compiler’s implementation details.
>

I'm interested in more information about this. What sorts of code have you
been writing where a file would have to be thousands of lines long in order
to accommodate `fileprivate`? Many entire modules are only thousands of
lines long--is there a reason this code couldn't be refactored into a
module of its own? As mentioned by Matthew, isn't this calling for some
notion of submodules?

What it would basically come down to is that the interface of the object
> would be separated in to blocks based on your access privileges. When
> viewing the interface, it wouldn’t look much different to an extension:
>
> *access(public)* class TabController {
>var tabs : [Tab] { get }
>func closeTab(at: Int)
> }
>
> *access(TabBarStuff)* extension TabController {
> func close(tab: Tab)
> }
>
> I definitely want something between internal and fileprivate, at least. I
> don’t see any reason at all why objects shouldn’t be allowed to present
> optional “slices” of their interface to appropriate clients. In fact, that
> is what access control is all about. I just want to generalise it to allow
> for user-defined visibility scopes (as well as the default ones for public,
> module, file and scope). That leads to the question of what visibility
> those user-defined scopes would have; and if you leave them entirely open
> to adopt any scope (except themselves), then you end up with the ability to
> slice your API for different use-cases. Or we could be boring and limit
> them to the module they are defined in.
>
> The whole reason I’m bringing this up is because I don’t like the “file”
> part of fileprivate. How I split my files up is a readability decision.
>
> Karl
>
> ___
> 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

Re: [swift-evolution] private & fileprivate

[Rien via swift-evolution]

> On 08 Oct 2016, at 19:17, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
> 
> Sent from my iPad
> 
> On Oct 8, 2016, at 12:02 PM, Karl via swift-evolution 
>  wrote:
> 
>> 
>>> On 8 Oct 2016, at 16:47, Braeden Profile  wrote:
>>> 
 
 On Oct 8, 2016, at 6:58 AM, Karl via swift-evolution 
  wrote:
 
 I was thinking that the domains themselves could be associated with a 
 domain, so you could create alternate domains which are also 
 publicly-visible, but distinct from the default, “public” domain.
 
 For example, if you have a bunch of methods which should be visible to 
 subclasses, but you don’t want them to clutter your regular interface. 
 Perhaps they have names which are confusingly-similar to the public API. I 
 believe that is what “protected” is typically used for.
>>> 
>>> Yes, but “protected" was specifically put down by the core team, seeing 
>>> that any code from outside the library should see the class as one 
>>> well-designed whole, not something with complicated, visible implementation 
>>> details.  If your class-internal methods are confusing (and aren’t 
>>> necessary for normal use), they shouldn’t be made public in any way.  
>>> Subclasses would too easily confuse the distinction between your 
>>> implementation methods and your public ones.
>>> 
>>> For what it’s worth, I was only confused by “private” and “fileprivate” for 
>>> a minute or two until I looked up the actual proposal.  I haven’t had 
>>> trouble with it, and it does actually provide more flexibility for code 
>>> access at the file level than we had before.  Even if the syntax is clunky.
>> 
>> I’m not saying that (file)private is confusing - it’s very clear about what 
>> it does. But it is limiting; anything that wants access to those 
>> semi-private details needs to live in the same file. That’s clearly not 
>> scalable. Enormous files many thousands of lines long are easy for the 
>> compiler to digest, but less easy for humans to understand and navigate. In 
>> fact, I believe this whole “file-based” access control originally came out 
>> of the compiler’s implementation details.
>> 
>> What it would basically come down to is that the interface of the object 
>> would be separated in to blocks based on your access privileges. When 
>> viewing the interface, it wouldn’t look much different to an extension:
>> 
>> access(public) class TabController {
>>var tabs : [Tab] { get }
>>func closeTab(at: Int)
>> }
>> 
>> access(TabBarStuff) extension TabController {
>> func close(tab: Tab)
>> }
>> 
>> I definitely want something between internal and fileprivate, at least. I 
>> don’t see any reason at all why objects shouldn’t be allowed to present 
>> optional “slices” of their interface to appropriate clients. In fact, that 
>> is what access control is all about. I just want to generalise it to allow 
>> for user-defined visibility scopes (as well as the default ones for public, 
>> module, file and scope). That leads to the question of what visibility those 
>> user-defined scopes would have; and if you leave them entirely open to adopt 
>> any scope (except themselves), then you end up with the ability to slice 
>> your API for different use-cases. Or we could be boring and limit them to 
>> the module they are defined in.
>> 
>> The whole reason I’m bringing this up is because I don’t like the “file” 
>> part of fileprivate. How I split my files up is a readability decision.
> 
> It seems to me that some kind of submodule facility is probably the best way 
> to accomplish what you describe here.

fileextension MyClass.swift

> 
>> 
>> Karl
>> ___
>> 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

Re: [swift-evolution] private & fileprivate

[Braeden Profile via swift-evolution]

> 
> On Oct 8, 2016, at 6:58 AM, Karl via swift-evolution 
>  wrote:
> 
> I was thinking that the domains themselves could be associated with a domain, 
> so you could create alternate domains which are also publicly-visible, but 
> distinct from the default, “public” domain.
> 
> For example, if you have a bunch of methods which should be visible to 
> subclasses, but you don’t want them to clutter your regular interface. 
> Perhaps they have names which are confusingly-similar to the public API. I 
> believe that is what “protected” is typically used for.

Yes, but “protected" was specifically put down by the core team, seeing that 
any code from outside the library should see the class as one well-designed 
whole, not something with complicated, visible implementation details.  If your 
class-internal methods are confusing (and aren’t necessary for normal use), 
they shouldn’t be made public in any way.  Subclasses would too easily confuse 
the distinction between your implementation methods and your public ones.

For what it’s worth, I was only confused by “private” and “fileprivate” for a 
minute or two until I looked up the actual proposal.  I haven’t had trouble 
with it, and it does actually provide more flexibility for code access at the 
file level than we had before.  Even if the syntax is clunky.

> 
>> On 8 Oct 2016, at 13:28, Shawn Erickson > > wrote:
>> 
>> I agree something like you suggest will give a lot of flexibility without - 
>> I think - the IMHO quirkiness of friends in C++. It seems like the access 
>> domains must? be limited to inside a module to avoid potential surprises 
>> from outside the module?
>> 
>> -Shawn
>> 
>> On Sat, Oct 8, 2016 at 3:38 AM Karl via swift-evolution 
>> > wrote:
>> 
>>> On 8 Oct 2016, at 11:31, Haravikk via swift-evolution 
>>> > wrote:
>>> 
>>> 
 On 7 Oct 2016, at 22:44, Tony Allevato via swift-evolution 
 > wrote:
 personally I thought `private` was fine the way it was when it meant 
 `fileprivate` and I had no real need for `private` as it exists in Swift 3.
>>> 
>>> I have to agree with this; I wasn't especially comfortable with the change 
>>> (or the eventual choice of keyword style) and in practice I just don't find 
>>> it useful. I haven't used the new "private" even once since it was added, 
>>> except by accident, the only form of private I use is fileprivate.
>>> 
>>> I've happily embraced the conform through extension style in Swift, and 
>>> really when it comes down to it the new private access level just isn't 
>>> compatible with that style of development. It's only really useful for 
>>> hiding details of something you add in one specific section, which I almost 
>>> never do (and when I do I just mark it fileprivate in case I can re-use it).
>>> 
>>> Maybe some people do find it useful, but I'd prefer fileprivate to be the 
>>> default behaviour of private; the current (scoped?) private access level 
>>> seems far more limited, thus more deserving of a less convenient keyword, 
>>> or some kind of modifier on private. But personally I'd be fine with 
>>> removing it, as I don't think it really adds anything that fileprivate 
>>> doesn't already cover.
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
>> 
>> Sometimes you have multiple types inside a single file (because you want to 
>> share some fileprivate stuff but not make it internal), so it’s handy for 
>> that.
>> 
>> But you’re right that the syntax is totally ugly. I think access control is 
>> actually once of the biggest weak points of Swift - we should have a way for 
>> more arbitrary access control, similar to “friend classes” in C++. So then 
>> all of your types don’t need to be stuffed inside the same file in order to 
>> share semi-private implementation details. “Internal” is scoped to modules, 
>> but many people have also expressed the desire for sub-modules or namespaces 
>> and often resort to nasty things like caseless enums or empty structs (why 
>> nasty? because they don’t really define types - they’re just used for 
>> grouping purposes, and we should have a separate construct for that). So 
>> then we may need some way for these sub-modules to share some semi-private 
>> implementation details, etc…
>> 
>> I would prefer if we could define some kind of access-domain, and you could 
>> assign members or types to those domains. We could possibly have some kind 
>> of user-defined access-domains, which you could opt-in to in order to see 
>> more details about a 

Re: [swift-evolution] private & fileprivate

[Anton Zhilin via swift-evolution]

As far as I can see, almost all people, who talk here, agree that private /
fileprivate distinction brought more harm than good. Despite corresponding
proposal being accepted.
I think, it means that current mailing-list system is failing. Let's accept
it, gmane looks and feels ugly by comparison to forums. And using email
limits the number of people involved by an order of magnitude.
What we need is popularization of SE, reaching as many developers as we
can, using simple voting, likes, and so on.

2016-10-08 12:31 GMT+03:00 Haravikk via swift-evolution <
swift-evolution@swift.org>:

>
> > On 7 Oct 2016, at 22:44, Tony Allevato via swift-evolution <
> swift-evolution@swift.org> wrote:
> > personally I thought `private` was fine the way it was when it meant
> `fileprivate` and I had no real need for `private` as it exists in Swift 3.
>
> I have to agree with this; I wasn't especially comfortable with the change
> (or the eventual choice of keyword style) and in practice I just don't find
> it useful. I haven't used the new "private" even once since it was added,
> except by accident, the only form of private I use is fileprivate.
>
> I've happily embraced the conform through extension style in Swift, and
> really when it comes down to it the new private access level just isn't
> compatible with that style of development. It's only really useful for
> hiding details of something you add in one specific section, which I almost
> never do (and when I do I just mark it fileprivate in case I can re-use it).
>
> Maybe some people do find it useful, but I'd prefer fileprivate to be the
> default behaviour of private; the current (scoped?) private access level
> seems far more limited, thus more deserving of a less convenient keyword,
> or some kind of modifier on private. But personally I'd be fine with
> removing it, as I don't think it really adds anything that fileprivate
> doesn't already cover.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] private & fileprivate

[Karl via swift-evolution]

I was thinking that the domains themselves could be associated with a domain, 
so you could create alternate domains which are also publicly-visible, but 
distinct from the default, “public” domain.

For example, if you have a bunch of methods which should be visible to 
subclasses, but you don’t want them to clutter your regular interface. Perhaps 
they have names which are confusingly-similar to the public API. I believe that 
is what “protected” is typically used for.

> On 8 Oct 2016, at 13:28, Shawn Erickson  wrote:
> 
> I agree something like you suggest will give a lot of flexibility without - I 
> think - the IMHO quirkiness of friends in C++. It seems like the access 
> domains must? be limited to inside a module to avoid potential surprises from 
> outside the module?
> 
> -Shawn
> 
> On Sat, Oct 8, 2016 at 3:38 AM Karl via swift-evolution 
> > wrote:
> 
>> On 8 Oct 2016, at 11:31, Haravikk via swift-evolution 
>> > wrote:
>> 
>> 
>>> On 7 Oct 2016, at 22:44, Tony Allevato via swift-evolution 
>>> > wrote:
>>> personally I thought `private` was fine the way it was when it meant 
>>> `fileprivate` and I had no real need for `private` as it exists in Swift 3.
>> 
>> I have to agree with this; I wasn't especially comfortable with the change 
>> (or the eventual choice of keyword style) and in practice I just don't find 
>> it useful. I haven't used the new "private" even once since it was added, 
>> except by accident, the only form of private I use is fileprivate.
>> 
>> I've happily embraced the conform through extension style in Swift, and 
>> really when it comes down to it the new private access level just isn't 
>> compatible with that style of development. It's only really useful for 
>> hiding details of something you add in one specific section, which I almost 
>> never do (and when I do I just mark it fileprivate in case I can re-use it).
>> 
>> Maybe some people do find it useful, but I'd prefer fileprivate to be the 
>> default behaviour of private; the current (scoped?) private access level 
>> seems far more limited, thus more deserving of a less convenient keyword, or 
>> some kind of modifier on private. But personally I'd be fine with removing 
>> it, as I don't think it really adds anything that fileprivate doesn't 
>> already cover.
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 
> 
> Sometimes you have multiple types inside a single file (because you want to 
> share some fileprivate stuff but not make it internal), so it’s handy for 
> that.
> 
> But you’re right that the syntax is totally ugly. I think access control is 
> actually once of the biggest weak points of Swift - we should have a way for 
> more arbitrary access control, similar to “friend classes” in C++. So then 
> all of your types don’t need to be stuffed inside the same file in order to 
> share semi-private implementation details. “Internal” is scoped to modules, 
> but many people have also expressed the desire for sub-modules or namespaces 
> and often resort to nasty things like caseless enums or empty structs (why 
> nasty? because they don’t really define types - they’re just used for 
> grouping purposes, and we should have a separate construct for that). So then 
> we may need some way for these sub-modules to share some semi-private 
> implementation details, etc…
> 
> I would prefer if we could define some kind of access-domain, and you could 
> assign members or types to those domains. We could possibly have some kind of 
> user-defined access-domains, which you could opt-in to in order to see more 
> details about a type (so you could expose it for subclassing purposes, like 
> “protected”, or in any other more arbitrary way).
> 
> So it might look something like:
> 
> @access-domain TabBarStuff // the domain itself has an access-domain
> 
> class TabController {
> var tabs: [Tab]
> 
> access(public) func closeTab(at: Int) { … }
> access(TabBarStuff) func close(tab: Tab) { … }
> }
> 
> // Another file. Must be in the same module due to access-domain 
> “TabBarStuff”’s visibility
> 
> class Tab {
>unowned var controller : TabController access(TabBarStuff)
> 
> func close() { controller.close(tab: self) }
> }
> 
> In this case, our API design means that in TabController.close(tab:), we will 
> never get a Tab from a different TabController. This is a nice feature to 
> have, but it requires TabController and Tab to share a member which is not 
> visible to other types. Currently, that means we must have types or 
> extensions scattered around in different files 

Re: [swift-evolution] private & fileprivate

[Shawn Erickson via swift-evolution]

I agree something like you suggest will give a lot of flexibility without -
I think - the IMHO quirkiness of friends in C++. It seems like the access
domains must? be limited to inside a module to avoid potential surprises
from outside the module?

-Shawn

On Sat, Oct 8, 2016 at 3:38 AM Karl via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On 8 Oct 2016, at 11:31, Haravikk via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On 7 Oct 2016, at 22:44, Tony Allevato via swift-evolution <
> swift-evolution@swift.org> wrote:
> personally I thought `private` was fine the way it was when it meant
> `fileprivate` and I had no real need for `private` as it exists in Swift 3.
>
>
> I have to agree with this; I wasn't especially comfortable with the change
> (or the eventual choice of keyword style) and in practice I just don't find
> it useful. I haven't used the new "private" even once since it was added,
> except by accident, the only form of private I use is fileprivate.
>
> I've happily embraced the conform through extension style in Swift, and
> really when it comes down to it the new private access level just isn't
> compatible with that style of development. It's only really useful for
> hiding details of something you add in one specific section, which I almost
> never do (and when I do I just mark it fileprivate in case I can re-use it).
>
> Maybe some people do find it useful, but I'd prefer fileprivate to be the
> default behaviour of private; the current (scoped?) private access level
> seems far more limited, thus more deserving of a less convenient keyword,
> or some kind of modifier on private. But personally I'd be fine with
> removing it, as I don't think it really adds anything that fileprivate
> doesn't already cover.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> Sometimes you have multiple types inside a single file (because you want
> to share some fileprivate stuff but not make it internal), so it’s handy
> for that.
>
> But you’re right that the syntax is totally ugly. I think access control
> is actually once of the biggest weak points of Swift - we should have a way
> for more arbitrary access control, similar to “friend classes” in C++. So
> then all of your types don’t need to be stuffed inside the same file in
> order to share semi-private implementation details. “Internal” is scoped to
> modules, but many people have also expressed the desire for sub-modules or
> namespaces and often resort to nasty things like caseless enums or empty
> structs (why nasty? because they don’t really define types - they’re just
> used for grouping purposes, and we should have a separate construct for
> that). So then we may need some way for these sub-modules to share some
> semi-private implementation details, etc…
>
> I would prefer if we could define some kind of access-domain, and you
> could assign members or types to those domains. We could possibly have some
> kind of user-defined access-domains, which you could opt-in to in order to
> see more details about a type (so you could expose it for subclassing
> purposes, like “protected”, or in any other more arbitrary way).
>
> So it might look something like:
>
> *@access-domain TabBarStuff* // the domain itself has an access-domain
>
> class TabController {
> var tabs: [Tab]
>
> *access(public)* func closeTab(at: Int) { … }
> *access(TabBarStuff)* func close(tab: Tab) { … }
> }
>
> // Another file. Must be in the same module due to access-domain
> “TabBarStuff”’s visibility
>
> class Tab {
>unowned var controller : TabController *access(TabBarStuff)*
>
> func close() { *controller.close(tab: self)* }
> }
>
> In this case, our API design means that in TabController.close(tab:), we
> will never get a Tab from a different TabController. This is a nice feature
> to have, but it requires TabController and Tab to share a member which is
> not visible to other types. Currently, that means we must have types or
> extensions scattered around in different files to accommodate for access
> levels.
>
> Karl
> ___
> 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

Re: [swift-evolution] private & fileprivate

[Karl via swift-evolution]

> On 8 Oct 2016, at 11:31, Haravikk via swift-evolution 
>  wrote:
> 
> 
>> On 7 Oct 2016, at 22:44, Tony Allevato via swift-evolution 
>>  wrote:
>> personally I thought `private` was fine the way it was when it meant 
>> `fileprivate` and I had no real need for `private` as it exists in Swift 3.
> 
> I have to agree with this; I wasn't especially comfortable with the change 
> (or the eventual choice of keyword style) and in practice I just don't find 
> it useful. I haven't used the new "private" even once since it was added, 
> except by accident, the only form of private I use is fileprivate.
> 
> I've happily embraced the conform through extension style in Swift, and 
> really when it comes down to it the new private access level just isn't 
> compatible with that style of development. It's only really useful for hiding 
> details of something you add in one specific section, which I almost never do 
> (and when I do I just mark it fileprivate in case I can re-use it).
> 
> Maybe some people do find it useful, but I'd prefer fileprivate to be the 
> default behaviour of private; the current (scoped?) private access level 
> seems far more limited, thus more deserving of a less convenient keyword, or 
> some kind of modifier on private. But personally I'd be fine with removing 
> it, as I don't think it really adds anything that fileprivate doesn't already 
> cover.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution


Sometimes you have multiple types inside a single file (because you want to 
share some fileprivate stuff but not make it internal), so it’s handy for that.

But you’re right that the syntax is totally ugly. I think access control is 
actually once of the biggest weak points of Swift - we should have a way for 
more arbitrary access control, similar to “friend classes” in C++. So then all 
of your types don’t need to be stuffed inside the same file in order to share 
semi-private implementation details. “Internal” is scoped to modules, but many 
people have also expressed the desire for sub-modules or namespaces and often 
resort to nasty things like caseless enums or empty structs (why nasty? because 
they don’t really define types - they’re just used for grouping purposes, and 
we should have a separate construct for that). So then we may need some way for 
these sub-modules to share some semi-private implementation details, etc…

I would prefer if we could define some kind of access-domain, and you could 
assign members or types to those domains. We could possibly have some kind of 
user-defined access-domains, which you could opt-in to in order to see more 
details about a type (so you could expose it for subclassing purposes, like 
“protected”, or in any other more arbitrary way).

So it might look something like:

@access-domain TabBarStuff // the domain itself has an access-domain

class TabController {
var tabs: [Tab]

access(public) func closeTab(at: Int) { … }
access(TabBarStuff) func close(tab: Tab) { … }
}

// Another file. Must be in the same module due to access-domain 
“TabBarStuff”’s visibility

class Tab {
   unowned var controller : TabController access(TabBarStuff)

func close() { controller.close(tab: self) }
}

In this case, our API design means that in TabController.close(tab:), we will 
never get a Tab from a different TabController. This is a nice feature to have, 
but it requires TabController and Tab to share a member which is not visible to 
other types. Currently, that means we must have types or extensions scattered 
around in different files to accommodate for access levels.

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

Re: [swift-evolution] private & fileprivate

[Haravikk via swift-evolution]

> On 7 Oct 2016, at 22:44, Tony Allevato via swift-evolution 
>  wrote:
> personally I thought `private` was fine the way it was when it meant 
> `fileprivate` and I had no real need for `private` as it exists in Swift 3.

I have to agree with this; I wasn't especially comfortable with the change (or 
the eventual choice of keyword style) and in practice I just don't find it 
useful. I haven't used the new "private" even once since it was added, except 
by accident, the only form of private I use is fileprivate.

I've happily embraced the conform through extension style in Swift, and really 
when it comes down to it the new private access level just isn't compatible 
with that style of development. It's only really useful for hiding details of 
something you add in one specific section, which I almost never do (and when I 
do I just mark it fileprivate in case I can re-use it).

Maybe some people do find it useful, but I'd prefer fileprivate to be the 
default behaviour of private; the current (scoped?) private access level seems 
far more limited, thus more deserving of a less convenient keyword, or some 
kind of modifier on private. But personally I'd be fine with removing it, as I 
don't think it really adds anything that fileprivate doesn't already cover.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] private & fileprivate

[Muse M via swift-evolution]

I would rather consider using a new keyword that could make it clearer
without looking up for description.

NewCurrent
moduleprivate over internal



On Sat, Oct 8, 2016 at 2:44 PM, Rien via swift-evolution <
swift-evolution@swift.org> wrote:

> +1 for me.
>
> I see a little benefit for teams that have multiple people working on a
> single file (not necessarily at the same time) where a case can be made for
> a distinction between fileprivate and private. Other than that there is imo
> no benefit. So to me the question is “is the benefit to those teams worth
> the burden on the rest of us”?
>
> I honestly do not know the answer to that.
>
> Personally I come down on the side of reverting this change.
>
> Btw: I was not present during the original discussion. If I had been I
> would have tried to make a case for a “friends list”. In which each scope
> could have a list of “friends” that have “private” access. This has the
> advantage that all external access to the scope would be documentation in
> that scope, and it would open up the possibility of granting private access
> to closures outside the file the scope was defined in. (private would then
> become class-private and fileprivate could be eliminated)
>
> Rien.
>
> > On 07 Oct 2016, at 23:44, Tony Allevato via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > I actually feel exactly the opposite of this—personally I thought
> `private` was fine the way it was when it meant `fileprivate` and I had no
> real need for `private` as it exists in Swift 3.
> >
> > `fileprivate` is useful because it lets me organize my code in such a
> way that I divide large types (for example, those that conform to many
> delegates/other protocols) into multiple extensions in the same file. Any
> state or helpers that I want to keep in the main class can be defined as
> `fileprivate` and still be accessible throughout that file, without leaking
> them into the rest of my module if they were defined as `internal`.
> >
> > On the other hand, `private` would mostly just protect me from myself at
> a very small level. In all the Swift code that I've written (this is my
> anecdotal experience, of course, and I know others differ), it's rare that
> I've found a strong reason to or benefit from locking something down as
> `private` instead of `fileprivate`.
> >
> > Of course, one could argue that `fileprivate` is also protecting me from
> myself, just a file-based level instead of a scope-based level, but I think
> it would be more harmful to encourage leaking abstractions out of a file
> and into a module than it would to leak them out of a scope and into a
> single file. The affected surface area is much smaller in the latter case.
> >
> > One possible compromise that pops into my head would be to let `private`
> not apply to a scope but to a type and also to only those extensions on
> that type that are visible in the same file—that may have already been
> discussed during the review of the original proposal. I don't know what the
> complexity of it would be.
> >
> > Either way, I would be strongly against anything that removes
> `fileprivate`. I don't find much use for `private` and nobody is forcing me
> to use it, so I don't. On the other hand, removing `fileprivate` would
> prevent a design and code organization pattern that I enjoy about Swift.
> >
> >
> >
> > On Fri, Oct 7, 2016 at 2:06 PM Zach Waldowski via swift-evolution <
> swift-evolution@swift.org> wrote:
> > I third this sentiment. fileprivate is a nice idea and very clearly has
> its uses (which is why the proposal got traction in the first place), but
> when combined with the other access levels, the language feature as a whole
> feels arbitrary. In practical use, files that I felt were nicely
> encapsulated and hiding implementation details are now a scattered mix of
> access levels, adding cognitive load and making the code look unorganized
> for having the gall to use extensions to split up functionality.
> >
> > Sincerely,
> >   Zachary Waldowski
> >   z...@waldowski.me
> >
> >
> > On Fri, Oct 7, 2016, at 01:55 PM, Russ Bishop via swift-evolution wrote:
> >>
> >>> On Oct 7, 2016, at 9:13 AM, David Hart via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>>
> >>> I started the topic, but I also believe like you that the fileprivate
> vs private(file) discussion has already been thoroughly discussed and
> nothing new has been brought up. That’s not what I want to discuss.
> >>>
> >>> I instead want to share my experience using private and fileprivate
> since release. Here are my thoughts:
> >>>
> >>> • We should start with the premise that the proposal has added a
> substantial amount of complexity:
> >>> • It has added an extra modifier and access level to learn.
> >>> • It has complicated the access level rules with Inner
> types as mentioned in the Complications with private types section of the
> proposal.
> >>> • I have 

Re: [swift-evolution] private & fileprivate

[Rien via swift-evolution]

+1 for me.

I see a little benefit for teams that have multiple people working on a single 
file (not necessarily at the same time) where a case can be made for a 
distinction between fileprivate and private. Other than that there is imo no 
benefit. So to me the question is “is the benefit to those teams worth the 
burden on the rest of us”?

I honestly do not know the answer to that.

Personally I come down on the side of reverting this change.

Btw: I was not present during the original discussion. If I had been I would 
have tried to make a case for a “friends list”. In which each scope could have 
a list of “friends” that have “private” access. This has the advantage that all 
external access to the scope would be documentation in that scope, and it would 
open up the possibility of granting private access to closures outside the file 
the scope was defined in. (private would then become class-private and 
fileprivate could be eliminated)

Rien.

> On 07 Oct 2016, at 23:44, Tony Allevato via swift-evolution 
>  wrote:
> 
> I actually feel exactly the opposite of this—personally I thought `private` 
> was fine the way it was when it meant `fileprivate` and I had no real need 
> for `private` as it exists in Swift 3.
> 
> `fileprivate` is useful because it lets me organize my code in such a way 
> that I divide large types (for example, those that conform to many 
> delegates/other protocols) into multiple extensions in the same file. Any 
> state or helpers that I want to keep in the main class can be defined as 
> `fileprivate` and still be accessible throughout that file, without leaking 
> them into the rest of my module if they were defined as `internal`.
> 
> On the other hand, `private` would mostly just protect me from myself at a 
> very small level. In all the Swift code that I've written (this is my 
> anecdotal experience, of course, and I know others differ), it's rare that 
> I've found a strong reason to or benefit from locking something down as 
> `private` instead of `fileprivate`.
> 
> Of course, one could argue that `fileprivate` is also protecting me from 
> myself, just a file-based level instead of a scope-based level, but I think 
> it would be more harmful to encourage leaking abstractions out of a file and 
> into a module than it would to leak them out of a scope and into a single 
> file. The affected surface area is much smaller in the latter case.
> 
> One possible compromise that pops into my head would be to let `private` not 
> apply to a scope but to a type and also to only those extensions on that type 
> that are visible in the same file—that may have already been discussed during 
> the review of the original proposal. I don't know what the complexity of it 
> would be.
> 
> Either way, I would be strongly against anything that removes `fileprivate`. 
> I don't find much use for `private` and nobody is forcing me to use it, so I 
> don't. On the other hand, removing `fileprivate` would prevent a design and 
> code organization pattern that I enjoy about Swift.
> 
> 
> 
> On Fri, Oct 7, 2016 at 2:06 PM Zach Waldowski via swift-evolution 
>  wrote:
> I third this sentiment. fileprivate is a nice idea and very clearly has its 
> uses (which is why the proposal got traction in the first place), but when 
> combined with the other access levels, the language feature as a whole feels 
> arbitrary. In practical use, files that I felt were nicely encapsulated and 
> hiding implementation details are now a scattered mix of access levels, 
> adding cognitive load and making the code look unorganized for having the 
> gall to use extensions to split up functionality.
> 
> Sincerely,
>   Zachary Waldowski
>   z...@waldowski.me
> 
> 
> On Fri, Oct 7, 2016, at 01:55 PM, Russ Bishop via swift-evolution wrote:
>> 
>>> On Oct 7, 2016, at 9:13 AM, David Hart via swift-evolution 
>>>  wrote:
>>> 
>>> I started the topic, but I also believe like you that the fileprivate vs 
>>> private(file) discussion has already been thoroughly discussed and nothing 
>>> new has been brought up. That’s not what I want to discuss.
>>> 
>>> I instead want to share my experience using private and fileprivate since 
>>> release. Here are my thoughts:
>>> 
>>> • We should start with the premise that the proposal has added a 
>>> substantial amount of complexity:
>>> • It has added an extra modifier and access level to learn.
>>> • It has complicated the access level rules with Inner types as 
>>> mentioned in the Complications with private types section of the proposal.
>>> • I have seen many people (twitter, work, slack) be confused 
>>> about the difference between private and fileprivate at the global level. 
>>> The answer is none, which shows that both modifiers are not very orthogonal.
>>> • Since release, I saw people prefer one over the other, as a 
>>> matter of 

Re: [swift-evolution] private & fileprivate

[David Hart via swift-evolution]

Comments inline:

> On 8 Oct 2016, at 00:56, Jordan Rose via swift-evolution 
>  wrote:
> 
> 
>>> On Oct 7, 2016, at 15:15, William Sumner via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> On Oct 7, 2016, at 3:05 PM, Zach Waldowski via swift-evolution 
>>>  wrote:
>>> 
>>> I third this sentiment. fileprivate is a nice idea and very clearly has its 
>>> uses (which is why the proposal got traction in the first place), but when  
>>> combined with the other access levels, the language feature as a whole 
>>> feels arbitrary. In practical use, files that I felt were nicely 
>>> encapsulated and hiding implementation details are now a scattered mix of 
>>> access levels, adding cognitive load and making the code look unorganized 
>>> for having the gall to use extensions to split up functionality.
>>> 
>>> Sincerely,
>>>   Zachary Waldowski
>>>   z...@waldowski.me
>> 
>> Beyond the textual change of using a different modifier name, I don’t see 
>> how the encapsulation and organization of code could be affected. Really, 
>> there’s not much point in rehashing prior discussion of SE-0025 unless 
>> there’s a previously unconsidered angle.
> 
> I strongly agree with this sentiment. SE-0025 was very heavily discussed, and 
> while many people were not satisfied with the solution we went with 
> (including me!), it was what the core team and community converged on. I 
> don't expect us to change access control again until and unless we decide to 
> change the model in some way, and even then I think we'll want to go through 
> extra effort to maintain compatibility with Swift 3. As has been mentioned 
> repeatedly, the bar for source-breaking changes is much higher than it was in 
> the first few months of swift-evolution.
> 
> I actually consider it very lucky that most of our changes so far have been 
> fairly non-controversial.

I agree. But I think this one is different, and that's why I brought it up :)

> Everybody has a different idea of what would make Swift a better language, 
> and all of us well-meaning. But when those ideas conflict, some group is 
> going to end up unhappy. I'm actually very glad that (a) we haven't had too 
> many of these cases, and (b) even when we have, people have been able to 
> accept it and move on to contributing to the next issue.

For me, this is not a question of people being unhappy. I've seen create 
confusion to both old and new Swift developers.

> Jordan
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] private & fileprivate

[Xiaodi Wu via swift-evolution]

On Fri, Oct 7, 2016 at 8:49 PM, Braeden Profile via swift-evolution <
swift-evolution@swift.org> wrote:

> >
> > On Oct 7, 2016, at 5:46 PM, Trans via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Private access that limits exposure to extensions and subclasses is
> > the bane of reusability. It sucks in Java and it sucks in Swift. As
> > far as I know Ruby is the only language that seems to get that.
>
> Agreed.  Reading this thread, almost everyone’s presented actual use cases
> would be fixed if we could do something functionally equivalent to
> private(type) (even if that’s not the best syntax).  If we could have the
> ability to write extensions for a type throughout a module and access its
> private properties (and private subtypes, methods, etc.), then the ugliness
> introduced by fileprivate would be all but eliminated.  That’s an access
> level I would love.
>
> I do want to mention, though, that while I would enjoy C++-style
> type-level private, I don’t want protected.  The rationale for avoiding
> that in Swift is fantastic.


If I recall correctly, this idea was also put forward during the original
SE-0025 discussions. However, the design we have now was chosen over this
alternative and others. I was one of those people who didn't really like
the new private, didn't like `fileprivate`, and generally felt that
alternative designs (or even the Swift 2 status quo) could be superior.
But, the discussion was had, all of these viewpoints and more were aired
and mulled over, and a consensus was reached. It'd have to be some
startling new insight to justify yet another change for Swift 4.

> ___
> > 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

Re: [swift-evolution] private & fileprivate

[Braeden Profile via swift-evolution]

> 
> On Oct 7, 2016, at 5:46 PM, Trans via swift-evolution 
>  wrote:
> 
> Private access that limits exposure to extensions and subclasses is
> the bane of reusability. It sucks in Java and it sucks in Swift. As
> far as I know Ruby is the only language that seems to get that.

Agreed.  Reading this thread, almost everyone’s presented actual use cases 
would be fixed if we could do something functionally equivalent to 
private(type) (even if that’s not the best syntax).  If we could have the 
ability to write extensions for a type throughout a module and access its 
private properties (and private subtypes, methods, etc.), then the ugliness 
introduced by fileprivate would be all but eliminated.  That’s an access level 
I would love.

I do want to mention, though, that while I would enjoy C++-style type-level 
private, I don’t want protected.  The rationale for avoiding that in Swift is 
fantastic.

> ___
> 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

Re: [swift-evolution] private & fileprivate

[Zach Waldowski via swift-evolution]

On Fri, Oct 7, 2016, at 03:56 PM, Jordan Rose wrote:
> SE-0025 was *very* heavily discussed, and while many people were not
> satisfied with the solution we went with (including me!), it was what
> the core team and community converged on.

Politely playing the Devil's Advocate: it was still fairly early on in
the lifecycle of swift-evolution, particularly for the 3 cycle; the
discussion was heavily weighted towards the people who wanted a change,
versus those who were happy with the status quo. I don't like playing
the Silent Majority card, as it's a horribly weak fallacy, but it is
what it is.

(responding up-thread now to William…)

>>> On Oct 7, 2016, at 15:15, William Sumner via swift-evolution >> evolut...@swift.org> wrote:
>>>
>>> Really, there’s not much point in rehashing prior discussion of SE-
>>> 0025 unless there’s a previously unconsidered angle.

The new information is that Swift 3 is in the wild. People have gotten
to use it, users both new and old, and have been dismayed and confused,
respectively, with the change.

I appreciate the need for the community to keep pushing forward and not
constantly revisit and counter-proposal things, I really do. It's why I
was glad it seemed like "requiring `self.`" was laid to bed so
conclusively. But this isn't like C-style for loops, I'm not clinging to
my guns and incrementors; we've taken something that enjoyed a quite
simple mental model, even though it was limited compared to other
languages, and made it arbitrarily more complex.

Having come to a consensus (which I disagree happened; more the clock
ran ) shouldn't mean it's locked in stone forever. In fact, the
potential for reconsidering was mentioned by many in response to the
blowback to sealed-by-default, and was  used for justification as to why
it "had" to be considered for Swift 3.

It's important to recognize our mistakes and not get into the trap of
thinking the mailing list is the ground truth of all  Swift users.

Best —
Zach
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] private & fileprivate

[T.J. Usiyan via swift-evolution]

While I agree that private/fileprivate didn't change much… I have to say
that I wish we had simply kept private as is and ended up with private,
internal, public, and open. It is more tricky to explain than it is worth.

TJ


On Fri, Oct 7, 2016 at 6:56 PM, Jordan Rose via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Oct 7, 2016, at 15:15, William Sumner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Oct 7, 2016, at 3:05 PM, Zach Waldowski via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I third this sentiment. fileprivate is a nice idea and very clearly has
> its uses (which is why the proposal got traction in the first place), but
> when combined with the other access levels, the language feature as a whole
> feels arbitrary. In practical use, files that I felt were nicely
> encapsulated and hiding implementation details are now a scattered mix of
> access levels, adding cognitive load and making the code look unorganized
> for having the gall to use extensions to split up functionality.
>
> Sincerely,
>   Zachary Waldowski
>   z...@waldowski.me
>
>
> Beyond the textual change of using a different modifier name, I don’t see
> how the encapsulation and organization of code could be affected. Really,
> there’s not much point in rehashing prior discussion of SE-0025 unless
> there’s a previously unconsidered angle.
>
>
> I *strongly* agree with this sentiment. SE-0025 was *very* heavily
> discussed, and while many people were not satisfied with the solution we
> went with (including me!), it was what the core team and community
> converged on. I don't expect us to change access control again until and
> unless we decide to change the model in some way, and even then I think
> we'll want to go through extra effort to maintain compatibility with Swift
> 3. As has been mentioned repeatedly, the bar for source-breaking changes is
> much higher than it was in the first few months of swift-evolution.
>
> I actually consider it very lucky that most of our changes so far have
> been fairly non-controversial. Everybody has a different idea of what would
> make Swift a better language, and all of us well-meaning. But when those
> ideas conflict, some group is going to end up unhappy. I'm actually very
> glad that (a) we haven't had too many of these cases, and (b) even when we
> have, people have been able to accept it and move on to contributing to the
> next issue.
>
> Jordan
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] private & fileprivate

[Jordan Rose via swift-evolution]

> On Oct 7, 2016, at 15:15, William Sumner via swift-evolution 
>  wrote:
> 
> 
>> On Oct 7, 2016, at 3:05 PM, Zach Waldowski via swift-evolution 
>> > wrote:
>> 
>> I third this sentiment. fileprivate is a nice idea and very clearly has its 
>> uses (which is why the proposal got traction in the first place), but when 
>> combined with the other access levels, the language feature as a whole feels 
>> arbitrary. In practical use, files that I felt were nicely encapsulated and 
>> hiding implementation details are now a scattered mix of access levels, 
>> adding cognitive load and making the code look unorganized for having the 
>> gall to use extensions to split up functionality.
>> 
>> Sincerely,
>>   Zachary Waldowski
>>   z...@waldowski.me 
> 
> Beyond the textual change of using a different modifier name, I don’t see how 
> the encapsulation and organization of code could be affected. Really, there’s 
> not much point in rehashing prior discussion of SE-0025 unless there’s a 
> previously unconsidered angle.

I strongly agree with this sentiment. SE-0025 was very heavily discussed, and 
while many people were not satisfied with the solution we went with (including 
me!), it was what the core team and community converged on. I don't expect us 
to change access control again until and unless we decide to change the model 
in some way, and even then I think we'll want to go through extra effort to 
maintain compatibility with Swift 3. As has been mentioned repeatedly, the bar 
for source-breaking changes is much higher than it was in the first few months 
of swift-evolution.

I actually consider it very lucky that most of our changes so far have been 
fairly non-controversial. Everybody has a different idea of what would make 
Swift a better language, and all of us well-meaning. But when those ideas 
conflict, some group is going to end up unhappy. I'm actually very glad that 
(a) we haven't had too many of these cases, and (b) even when we have, people 
have been able to accept it and move on to contributing to the next issue.

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

Re: [swift-evolution] private & fileprivate

[William Sumner via swift-evolution]

> On Oct 7, 2016, at 3:05 PM, Zach Waldowski via swift-evolution 
>  wrote:
> 
> I third this sentiment. fileprivate is a nice idea and very clearly has its 
> uses (which is why the proposal got traction in the first place), but when 
> combined with the other access levels, the language feature as a whole feels 
> arbitrary. In practical use, files that I felt were nicely encapsulated and 
> hiding implementation details are now a scattered mix of access levels, 
> adding cognitive load and making the code look unorganized for having the 
> gall to use extensions to split up functionality.
> 
> Sincerely,
>   Zachary Waldowski
>   z...@waldowski.me 

Beyond the textual change of using a different modifier name, I don’t see how 
the encapsulation and organization of code could be affected. Really, there’s 
not much point in rehashing prior discussion of SE-0025 unless there’s a 
previously unconsidered angle.

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

Re: [swift-evolution] private & fileprivate

[Tony Allevato via swift-evolution]

I actually feel exactly the opposite of this—personally I thought `private`
was fine the way it was when it meant `fileprivate` and I had no real need
for `private` as it exists in Swift 3.

`fileprivate` is useful because it lets me organize my code in such a way
that I divide large types (for example, those that conform to many
delegates/other protocols) into multiple extensions in the same file. Any
state or helpers that I want to keep in the main class can be defined as
`fileprivate` and still be accessible throughout that file, without leaking
them into the rest of my module if they were defined as `internal`.

On the other hand, `private` would mostly just protect me from myself at a
very small level. In all the Swift code that I've written (this is my
anecdotal experience, of course, and I know others differ), it's rare that
I've found a strong reason to or benefit from locking something down as
`private` instead of `fileprivate`.

Of course, one could argue that `fileprivate` is also protecting me from
myself, just a file-based level instead of a scope-based level, but I think
it would be more harmful to encourage leaking abstractions out of a file
and into a module than it would to leak them out of a scope and into a
single file. The affected surface area is much smaller in the latter case.

One possible compromise that pops into my head would be to let `private`
not apply to a scope but to a type and also to only those extensions on
that type that are visible in the same file—that may have already been
discussed during the review of the original proposal. I don't know what the
complexity of it would be.

Either way, I would be strongly against anything that removes
`fileprivate`. I don't find much use for `private` and nobody is forcing me
to use it, so I don't. On the other hand, removing `fileprivate` would
prevent a design and code organization pattern that I enjoy about Swift.



On Fri, Oct 7, 2016 at 2:06 PM Zach Waldowski via swift-evolution <
swift-evolution@swift.org> wrote:

> I third this sentiment. fileprivate is a nice idea and very clearly has
> its uses (which is why the proposal got traction in the first place), but
> when combined with the other access levels, the language feature as a whole
> feels arbitrary. In practical use, files that I felt were nicely
> encapsulated and hiding implementation details are now a scattered mix of
> access levels, adding cognitive load and making the code look unorganized
> for having the gall to use extensions to split up functionality.
>
> Sincerely,
>   Zachary Waldowski
>   z...@waldowski.me
>
>
> On Fri, Oct 7, 2016, at 01:55 PM, Russ Bishop via swift-evolution wrote:
>
>
> On Oct 7, 2016, at 9:13 AM, David Hart via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I started the topic, but I also believe like you that the *fileprivate*
> vs *private(file)* discussion has already been thoroughly discussed and
> nothing new has been brought up. That’s not what I want to discuss.
>
> I instead want to share my experience using *private* and *fileprivate*
> since release. Here are my thoughts:
>
>
>1. We should start with the premise that the proposal has added a
>substantial amount of complexity:
>1. It has added an extra modifier and access level to learn.
>   2. It has complicated the access level rules with Inner types as
>   mentioned in the *Complications with private types* section of the
>   proposal.
>   3. I have seen many people (twitter, work, slack) be confused about
>   the difference between *private* and *fileprivate* at the global
>   level. The answer is none, which shows that both modifiers are not very
>   orthogonal.
>   4. Since release, I saw people prefer one over the other, as a
>   matter of style. They tend to always use *fileprivate* or always
>   using *private*. In the latter case, functions and properties get
>   clumped in the same class scope instead of be written through multiple
>   extensions.
>   2. I have the impression that the motivations for the proposal are
>much less real in practice:
>1. The first motivation stated is: *"It is not clear whether the
>   implementation details are meant to be completely hidden or can be 
> shared
>   with some related code without the danger of misusing the APIs marked as
>   private.”* I’ve found that to be fairly rare in practice because
>   the implementation details only used to leak inside the same file, which
>   greatly reduces the dangers.
>   2. The second motivation stated is: *"It forces a one class per
>   file structure, which is very limiting." *First of all, this is
>   partly false. I think it forces putting classes which share 
> implementation
>   details in the same file, which I don’t think is necessarily a bad 
> thing.
>
>
> To summarise, it seems that the confusion the proposal brought over
> semantics and style are not worth the 

Re: [swift-evolution] private & fileprivate

[Shawn Erickson via swift-evolution]

I do see dislike of the name, I get that, I among others pushed for
alternate naming (kinda preferred keeping "private" at file scope).

What isn't clear to me is - at least for some - folks asking to remove it
what they actually mean... or what confusion actually exists other then
being something new / different then the past. I prefer to not rush to
quickly to remove something because of noise early in the adoption /
availability of Swift 3.

It seems like some folks may not realize the the old "private" basically
changed its name to "fileprivate" without any behavior change in its
"protection" scope. So when voting to remove fileprivate do they want to
lose file scoping as well or are they asking for the new private to change
back to be file scope (e.g. lose the new private scoping). I also have seen
some of the "mocking" of this feature being based on assuming that file
scope was added and serves no purpose when in fact we always had file
private scoping.

-Shawn

On Fri, Oct 7, 2016 at 2:17 PM Zach Waldowski via swift-evolution <
swift-evolution@swift.org> wrote:

> On Fri, Oct 7, 2016, at 02:08 PM, Shawn Erickson via swift-evolution wrote:
>
> Also based on what do we really see an issue with the addition of
> fileprivate? It seems more theory then examples of problems in the
> discussions I have seen.
>
>
> I've migrated multiple projects, both for my own use and for clients. I've
> taught Swift 3 to my colleagues as we upgrade, and have to help seasoned
> developers through confusion. I've taught Swift 3 to people who don't know
> Swift, and have to help novice developers through confusion. I watch as
> other developers fight this, such as on Twitter, while fileprivate is a
> joke unto its own. That's hardly theoretical.
>
> Sincerely,
>   Zachary Waldowski
>   z...@waldowski.me
>
> ___
> 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

Re: [swift-evolution] private & fileprivate

[Zach Waldowski via swift-evolution]

On Fri, Oct 7, 2016, at 02:08 PM, Shawn Erickson via swift-evolution wrote:
> Also based on what do we really see an issue with the addition of
> fileprivate? It seems more theory then examples of problems in the
> discussions I have seen.

I've migrated multiple projects, both for my own use and for clients.
I've taught Swift 3 to my colleagues as we upgrade, and have to help
seasoned developers through confusion. I've taught Swift 3 to people who
don't know Swift, and have to help novice developers through confusion.
I watch as other developers fight this, such as on Twitter, while
fileprivate is a joke unto its own. That's hardly theoretical.

Sincerely,
  Zachary Waldowski
  z...@waldowski.me
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] private & fileprivate

[Shawn Erickson via swift-evolution]

So are folks saying remove the concept of file private and keep the new
private behavior? ...or revert the whole thing? Also based on what do we
really see an issue with the addition of fileprivate? It seems more theory
then examples of problems in the discussions I have seen.

-Shawn
On Fri, Oct 7, 2016 at 2:05 PM Zach Waldowski via swift-evolution <
swift-evolution@swift.org> wrote:

> I third this sentiment. fileprivate is a nice idea and very clearly has
> its uses (which is why the proposal got traction in the first place), but
> when combined with the other access levels, the language feature as a whole
> feels arbitrary. In practical use, files that I felt were nicely
> encapsulated and hiding implementation details are now a scattered mix of
> access levels, adding cognitive load and making the code look unorganized
> for having the gall to use extensions to split up functionality.
>
> Sincerely,
>   Zachary Waldowski
>   z...@waldowski.me
>
>
> On Fri, Oct 7, 2016, at 01:55 PM, Russ Bishop via swift-evolution wrote:
>
>
> On Oct 7, 2016, at 9:13 AM, David Hart via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I started the topic, but I also believe like you that the *fileprivate*
> vs *private(file)* discussion has already been thoroughly discussed and
> nothing new has been brought up. That’s not what I want to discuss.
>
> I instead want to share my experience using *private* and *fileprivate*
> since release. Here are my thoughts:
>
>
>1. We should start with the premise that the proposal has added a
>substantial amount of complexity:
>1. It has added an extra modifier and access level to learn.
>   2. It has complicated the access level rules with Inner types as
>   mentioned in the *Complications with private types* section of the
>   proposal.
>   3. I have seen many people (twitter, work, slack) be confused about
>   the difference between *private* and *fileprivate* at the global
>   level. The answer is none, which shows that both modifiers are not very
>   orthogonal.
>   4. Since release, I saw people prefer one over the other, as a
>   matter of style. They tend to always use *fileprivate* or always
>   using *private*. In the latter case, functions and properties get
>   clumped in the same class scope instead of be written through multiple
>   extensions.
>   2. I have the impression that the motivations for the proposal are
>much less real in practice:
>1. The first motivation stated is: *"It is not clear whether the
>   implementation details are meant to be completely hidden or can be 
> shared
>   with some related code without the danger of misusing the APIs marked as
>   private.”* I’ve found that to be fairly rare in practice because
>   the implementation details only used to leak inside the same file, which
>   greatly reduces the dangers.
>   2. The second motivation stated is: *"It forces a one class per
>   file structure, which is very limiting." *First of all, this is
>   partly false. I think it forces putting classes which share 
> implementation
>   details in the same file, which I don’t think is necessarily a bad 
> thing.
>
>
> To summarise, it seems that the confusion the proposal brought over
> semantics and style are not worth the limited benefits that it brought. I’d
> be tempted to backtrack the proposal and re-introduce private as a file
> scoped access-level and deprecate fileprivate.
>
> Thoughts?
> David.
>
>
>
> I agree. The minor benefit that fileprivate brings is not worth the
> cognitive overhead it introduces. We should just admit it was a mistake and
> back it out. We can avoid source-breaking changes by making fileprivate a
> synonym for private and provide fixits/warnings for a release to give
> people a chance to move off it.
>
>
>
> Russ
>
> *___*
> 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

Re: [swift-evolution] private & fileprivate

[Zach Waldowski via swift-evolution]

I third this sentiment. fileprivate is a nice idea and very clearly has
its uses (which is why the proposal got traction in the first place),
but when  combined with the other access levels, the language feature as
a whole feels arbitrary. In practical use, files that I felt were nicely
encapsulated and hiding implementation details are now a scattered mix
of access levels, adding cognitive load and making the code look
unorganized for having the gall to use extensions to split up
functionality.

Sincerely,
  Zachary Waldowski
  z...@waldowski.me


On Fri, Oct 7, 2016, at 01:55 PM, Russ Bishop via swift-evolution wrote:
>
>> On Oct 7, 2016, at 9:13 AM, David Hart via swift-evolution > evolut...@swift.org> wrote:
>>
>> I started the topic, but I also believe like you that the
>> *fileprivate* vs *private(file)* discussion has already been
>> thoroughly discussed and nothing new has been brought up. That’s not
>> what I want to discuss.
>>
>> I instead want to share my experience using *private* and
>> *fileprivate* since release. Here are my thoughts:
>>
>>  1. We should start with the premise that the proposal has added a
>> substantial amount of complexity:
>>1. It has added an extra modifier and access level to learn.
>>2. It has complicated the access level rules with Inner types as
>>   mentioned in the *Complications with private types* section of
>>   the proposal.
>>3. I have seen many people (twitter, work, slack) be confused
>>   about the difference between *private* and *fileprivate* at the
>>   global level. The answer is none, which shows that both
>>   modifiers are not very orthogonal.
>>4. Since release, I saw people prefer one over the other, as a
>>   matter of style. They tend to always use *fileprivate* or
>>   always using *private*. In the latter case, functions and
>>   properties get clumped in the same class scope instead of be
>>   written through multiple extensions.
>>  2. I have the impression that the motivations for the proposal are
>> much less real in practice:
>>1. The first motivation stated is: *"It is not clear whether the
>>   implementation details are meant to be completely hidden or can
>>   be shared with some related code without the danger of misusing
>>   the APIs marked as private.”* I’ve found that to be fairly rare
>>   in practice because the implementation details only used to
>>   leak inside the same file, which greatly reduces the dangers.
>>2. The second motivation stated is: *"It forces a one class per
>>   file structure, which is very limiting." *First of all, this is
>>   partly false. I think it forces putting classes which share
>>   implementation details in the same file, which I don’t think is
>>   necessarily a bad thing.
>>
>> To summarise, it seems that the confusion the proposal brought over
>> semantics and style are not worth the limited benefits that it
>> brought. I’d be tempted to backtrack the proposal and re-introduce
>> private as a file scoped access-level and deprecate fileprivate.
>>
>> Thoughts?
>> David.
>>
>
>
> I agree. The minor benefit that fileprivate brings is not worth the
> cognitive overhead it introduces. We should just admit it was a
> mistake and back it out. We can avoid source-breaking changes by
> making fileprivate a synonym for private and provide fixits/warnings
> for a release to give people a chance to move off it.
>
>
>
> Russ
>
> _
> 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

Re: [swift-evolution] private & fileprivate

[Russ Bishop via swift-evolution]

> On Oct 7, 2016, at 9:13 AM, David Hart via swift-evolution 
>  wrote:
> 
> I started the topic, but I also believe like you that the fileprivate vs 
> private(file) discussion has already been thoroughly discussed and nothing 
> new has been brought up. That’s not what I want to discuss.
> 
> I instead want to share my experience using private and fileprivate since 
> release. Here are my thoughts:
> 
> We should start with the premise that the proposal has added a substantial 
> amount of complexity:
> It has added an extra modifier and access level to learn.
> It has complicated the access level rules with Inner types as mentioned in 
> the Complications with private types section of the proposal.
> I have seen many people (twitter, work, slack) be confused about the 
> difference between private and fileprivate at the global level. The answer is 
> none, which shows that both modifiers are not very orthogonal.
> Since release, I saw people prefer one over the other, as a matter of style. 
> They tend to always use fileprivate or always using private. In the latter 
> case, functions and properties get clumped in the same class scope instead of 
> be written through multiple extensions.
> I have the impression that the motivations for the proposal are much less 
> real in practice:
> The first motivation stated is: "It is not clear whether the implementation 
> details are meant to be completely hidden or can be shared with some related 
> code without the danger of misusing the APIs marked as private.” I’ve found 
> that to be fairly rare in practice because the implementation details only 
> used to leak inside the same file, which greatly reduces the dangers.
> The second motivation stated is: "It forces a one class per file structure, 
> which is very limiting." First of all, this is partly false. I think it 
> forces putting classes which share implementation details in the same file, 
> which I don’t think is necessarily a bad thing.
> 
> To summarise, it seems that the confusion the proposal brought over semantics 
> and style are not worth the limited benefits that it brought. I’d be tempted 
> to backtrack the proposal and re-introduce private as a file scoped 
> access-level and deprecate fileprivate.
> 
> Thoughts?
> David.
> 


I agree. The minor benefit that fileprivate brings is not worth the cognitive 
overhead it introduces. We should just admit it was a mistake and back it out. 
We can avoid source-breaking changes by making fileprivate a synonym for 
private and provide fixits/warnings for a release to give people a chance to 
move off it.



Russ

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

Re: [swift-evolution] private & fileprivate

[Austin Zheng via swift-evolution]

> On Oct 7, 2016, at 9:13 AM, David Hart via swift-evolution 
>  wrote:
> 
> To summarise, it seems that the confusion the proposal brought over semantics 
> and style are not worth the limited benefits that it brought. I’d be tempted 
> to backtrack the proposal and re-introduce private as a file scoped 
> access-level and deprecate fileprivate.

This is my personal preference, to back out the fileprivate/private change 
before Swift becomes any more crystallized. That being said, I think the bar 
for 'novel insight' has to be very high for something like this to be a wise 
idea, lest we end up endlessly revisiting every idea that wasn't unanimously 
popular. Do we have any evidence the new access control system is proving a 
hindrance to developers, or specific information we didn't have during the 
original discussion?

Austin

> 
> Thoughts?
> David.
> 
>> On 7 Oct 2016, at 17:21, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> While no topic is formally off the table, to revisit a topic requires fresh 
>> insight. `private(file)` was suggested at the time and rejected in favor of 
>> `fileprivate`, and we really don't need another rehash of how much each 
>> person likes one or the other.
>> On Fri, Oct 7, 2016 at 09:02 Adriano Ferreira via swift-evolution 
>> > wrote:
>> +1
>> 
>> I would also rather have:
>> 
>> private(scope)
>> private(file)
>> private(module)
>> etc…
>> 
>> — A
>> 
>>> On Oct 7, 2016, at 4:24 AM, Haravikk via swift-evolution 
>>> > wrote:
>>> 
>>> 
 On 7 Oct 2016, at 07:39, David Hart via swift-evolution 
 > wrote:
 
 Hello community,
 
 From all the proposals which has gone into Swift 3, [SE-0025] Scoped 
 Access Level is the only one I’m having second thoughts about. Before 
 launching a discussion around it, I’m curious to know if it's worth 
 discussing it or if the “ship has sailed”. As the plan is to allow future 
 versions of Swift to break source-compatibility in certain rare scenarios, 
 perhaps we have a chance to reconsider certain proposals?
 
 Regards,
 David.
 ___
 swift-evolution mailing list
 swift-evolution@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-evolution 
 
>>> 
>>> What in particular don't you like about it?
>>> 
>>> Personally I still don't like the use of fileprivate as the keyword, I was 
>>> very much in favour of a bracketed system like:
>>> 
>>> private(scope)  Current private (I think, it doesn't appear to 
>>> be equivalent to protected in other languages anyway so I wouldn't call it 
>>> type).
>>> private(file)   Current fileprivate
>>> private(module) Current internal/default when omitted
>>> public  Current public
>>> 
>>> I favour this because it groups all restrictive access levels under private 
>>> (since they're all some form of private) with an optional modifier that's 
>>> explicit about what it's for. Also, it would have scope to move things like 
>>> final into a modifier too, so you might declare a method as public(final), 
>>> or public(open) if that's implemented later and so-on. Just seems like a 
>>> generally more flexible setup that also reduces the number of keywords 
>>> required.
>>> 
>>> Some may feel it's noisy, but personally I don't see it as a problem as it 
>>> always comes before the func/var/let keyword, generics and function name, 
>>> so it's not like it's near anything where the (minor) noise reduces 
>>> readability.
>>> 
>>> But yeah, having used the new fileprivate for a little while I just don't 
>>> like it; it may partly come down to the fact that I use fileprivate a lot 
>>> more than I use regular private. If we were to adopt the above scheme I 
>>> would recommend that private(file) be the default for use of the plain 
>>> private keyword, unless we gain the ability to specify private(type) (i.e- 
>>> protected in most other languages), as private(scope) seems like it's the 
>>> less common, at least in my experience.
>>> ___
>>> 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 
>> 
>> 

Re: [swift-evolution] private & fileprivate

[David Hart via swift-evolution]

I started the topic, but I also believe like you that the fileprivate vs 
private(file) discussion has already been thoroughly discussed and nothing new 
has been brought up. That’s not what I want to discuss.

I instead want to share my experience using private and fileprivate since 
release. Here are my thoughts:

We should start with the premise that the proposal has added a substantial 
amount of complexity:
It has added an extra modifier and access level to learn.
It has complicated the access level rules with Inner types as mentioned in the 
Complications with private types section of the proposal.
I have seen many people (twitter, work, slack) be confused about the difference 
between private and fileprivate at the global level. The answer is none, which 
shows that both modifiers are not very orthogonal.
Since release, I saw people prefer one over the other, as a matter of style. 
They tend to always use fileprivate or always using private. In the latter 
case, functions and properties get clumped in the same class scope instead of 
be written through multiple extensions.
I have the impression that the motivations for the proposal are much less real 
in practice:
The first motivation stated is: "It is not clear whether the implementation 
details are meant to be completely hidden or can be shared with some related 
code without the danger of misusing the APIs marked as private.” I’ve found 
that to be fairly rare in practice because the implementation details only used 
to leak inside the same file, which greatly reduces the dangers.
The second motivation stated is: "It forces a one class per file structure, 
which is very limiting." First of all, this is partly false. I think it forces 
putting classes which share implementation details in the same file, which I 
don’t think is necessarily a bad thing.

To summarise, it seems that the confusion the proposal brought over semantics 
and style are not worth the limited benefits that it brought. I’d be tempted to 
backtrack the proposal and re-introduce private as a file scoped access-level 
and deprecate fileprivate.

Thoughts?
David.

> On 7 Oct 2016, at 17:21, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> While no topic is formally off the table, to revisit a topic requires fresh 
> insight. `private(file)` was suggested at the time and rejected in favor of 
> `fileprivate`, and we really don't need another rehash of how much each 
> person likes one or the other.
> On Fri, Oct 7, 2016 at 09:02 Adriano Ferreira via swift-evolution 
> > wrote:
> +1
> 
> I would also rather have:
> 
> private(scope)
> private(file)
> private(module)
> etc…
> 
> — A
> 
>> On Oct 7, 2016, at 4:24 AM, Haravikk via swift-evolution 
>> > wrote:
>> 
>> 
>>> On 7 Oct 2016, at 07:39, David Hart via swift-evolution 
>>> > wrote:
>>> 
>>> Hello community,
>>> 
>>> From all the proposals which has gone into Swift 3, [SE-0025] Scoped Access 
>>> Level is the only one I’m having second thoughts about. Before launching a 
>>> discussion around it, I’m curious to know if it's worth discussing it or if 
>>> the “ship has sailed”. As the plan is to allow future versions of Swift to 
>>> break source-compatibility in certain rare scenarios, perhaps we have a 
>>> chance to reconsider certain proposals?
>>> 
>>> Regards,
>>> David.
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
>> What in particular don't you like about it?
>> 
>> Personally I still don't like the use of fileprivate as the keyword, I was 
>> very much in favour of a bracketed system like:
>> 
>>  private(scope)  Current private (I think, it doesn't appear to 
>> be equivalent to protected in other languages anyway so I wouldn't call it 
>> type).
>>  private(file)   Current fileprivate
>>  private(module) Current internal/default when omitted
>>  public  Current public
>> 
>> I favour this because it groups all restrictive access levels under private 
>> (since they're all some form of private) with an optional modifier that's 
>> explicit about what it's for. Also, it would have scope to move things like 
>> final into a modifier too, so you might declare a method as public(final), 
>> or public(open) if that's implemented later and so-on. Just seems like a 
>> generally more flexible setup that also reduces the number of keywords 
>> required.
>> 
>> Some may feel it's noisy, but personally I don't see it as a problem as it 
>> always comes before the func/var/let keyword, generics and function name, so 
>> it's not like it's near 

Re: [swift-evolution] private & fileprivate

[Adrian Kashivskyy via swift-evolution]

I’m +1 on the following:

current
new
private
private
fileprivate
private(file)
internal
private(module)
public
public
open
open
The only thing that keeps bothering me is private(set) and how it will 
harmonize with this proposed scheme.


Regards,
Adrian Kashivskyy

> Wiadomość napisana przez David Waite via swift-evolution 
>  w dniu 07.10.2016, o godz. 17:54:
> 
> I'd prefer to use public(file), etc over private. You are determining which 
> code has access over which code doesn't.  I don't think its that confusing to 
> say the default is just public(module)
> 
> Sent with my Thumbs
> 
> On Oct 7, 2016, at 9:21 AM, Xiaodi Wu via swift-evolution 
> > wrote:
> 
>> While no topic is formally off the table, to revisit a topic requires fresh 
>> insight. `private(file)` was suggested at the time and rejected in favor of 
>> `fileprivate`, and we really don't need another rehash of how much each 
>> person likes one or the other.
>> On Fri, Oct 7, 2016 at 09:02 Adriano Ferreira via swift-evolution 
>> > wrote:
>> +1
>> 
>> I would also rather have:
>> 
>> private(scope)
>> private(file)
>> private(module)
>> etc…
>> 
>> — A
>> 
>>> On Oct 7, 2016, at 4:24 AM, Haravikk via swift-evolution 
>>> > wrote:
>>> 
>>> 
 On 7 Oct 2016, at 07:39, David Hart via swift-evolution 
 > wrote:
 
 Hello community,
 
 From all the proposals which has gone into Swift 3, [SE-0025] Scoped 
 Access Level is the only one I’m having second thoughts about. Before 
 launching a discussion around it, I’m curious to know if it's worth 
 discussing it or if the “ship has sailed”. As the plan is to allow future 
 versions of Swift to break source-compatibility in certain rare scenarios, 
 perhaps we have a chance to reconsider certain proposals?
 
 Regards,
 David.
 ___
 swift-evolution mailing list
 swift-evolution@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-evolution 
 
>>> 
>>> What in particular don't you like about it?
>>> 
>>> Personally I still don't like the use of fileprivate as the keyword, I was 
>>> very much in favour of a bracketed system like:
>>> 
>>> private(scope)  Current private (I think, it doesn't appear to 
>>> be equivalent to protected in other languages anyway so I wouldn't call it 
>>> type).
>>> private(file)   Current fileprivate
>>> private(module) Current internal/default when omitted
>>> public  Current public
>>> 
>>> I favour this because it groups all restrictive access levels under private 
>>> (since they're all some form of private) with an optional modifier that's 
>>> explicit about what it's for. Also, it would have scope to move things like 
>>> final into a modifier too, so you might declare a method as public(final), 
>>> or public(open) if that's implemented later and so-on. Just seems like a 
>>> generally more flexible setup that also reduces the number of keywords 
>>> required.
>>> 
>>> Some may feel it's noisy, but personally I don't see it as a problem as it 
>>> always comes before the func/var/let keyword, generics and function name, 
>>> so it's not like it's near anything where the (minor) noise reduces 
>>> readability.
>>> 
>>> But yeah, having used the new fileprivate for a little while I just don't 
>>> like it; it may partly come down to the fact that I use fileprivate a lot 
>>> more than I use regular private. If we were to adopt the above scheme I 
>>> would recommend that private(file) be the default for use of the plain 
>>> private keyword, unless we gain the ability to specify private(type) (i.e- 
>>> protected in most other languages), as private(scope) seems like it's the 
>>> less common, at least in my experience.
>>> ___
>>> 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 
>> 
> 

Re: [swift-evolution] private & fileprivate

[Chris Lattner via swift-evolution]

> On Oct 6, 2016, at 11:39 PM, David Hart via swift-evolution 
>  wrote:
> 
> Hello community,
> 
> From all the proposals which has gone into Swift 3, [SE-0025] Scoped Access 
> Level is the only one I’m having second thoughts about. Before launching a 
> discussion around it, I’m curious to know if it's worth discussing it or if 
> the “ship has sailed”. As the plan is to allow future versions of Swift to 
> break source-compatibility in certain rare scenarios, perhaps we have a 
> chance to reconsider certain proposals?

We are always willing to consider new input, but any source breaking change has 
to provide overwhelming rationale for it being worth the cost to the community.

-Chris


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

Re: [swift-evolution] private & fileprivate

[David Waite via swift-evolution]

I'd prefer to use public(file), etc over private. You are determining which 
code has access over which code doesn't.  I don't think its that confusing to 
say the default is just public(module)

Sent with my Thumbs

> On Oct 7, 2016, at 9:21 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> While no topic is formally off the table, to revisit a topic requires fresh 
> insight. `private(file)` was suggested at the time and rejected in favor of 
> `fileprivate`, and we really don't need another rehash of how much each 
> person likes one or the other.
>> On Fri, Oct 7, 2016 at 09:02 Adriano Ferreira via swift-evolution 
>>  wrote:
>> +1
>> 
>> I would also rather have:
>> 
>> private(scope)
>> private(file)
>> private(module)
>> etc…
>> 
>> — A
>> 
 On Oct 7, 2016, at 4:24 AM, Haravikk via swift-evolution 
  wrote:
 
 
 On 7 Oct 2016, at 07:39, David Hart via swift-evolution 
  wrote:
 
 Hello community,
 
 From all the proposals which has gone into Swift 3, [SE-0025] Scoped 
 Access Level is the only one I’m having second thoughts about. Before 
 launching a discussion around it, I’m curious to know if it's worth 
 discussing it or if the “ship has sailed”. As the plan is to allow future 
 versions of Swift to break source-compatibility in certain rare scenarios, 
 perhaps we have a chance to reconsider certain proposals?
 
 Regards,
 David.
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> What in particular don't you like about it?
>>> 
>>> Personally I still don't like the use of fileprivate as the keyword, I was 
>>> very much in favour of a bracketed system like:
>>> 
>>> private(scope)  Current private (I think, it doesn't appear to 
>>> be equivalent to protected in other languages anyway so I wouldn't call it 
>>> type).
>>> private(file)   Current fileprivate
>>> private(module) Current internal/default when omitted
>>> public  Current public
>>> 
>>> I favour this because it groups all restrictive access levels under private 
>>> (since they're all some form of private) with an optional modifier that's 
>>> explicit about what it's for. Also, it would have scope to move things like 
>>> final into a modifier too, so you might declare a method as public(final), 
>>> or public(open) if that's implemented later and so-on. Just seems like a 
>>> generally more flexible setup that also reduces the number of keywords 
>>> required.
>>> 
>>> Some may feel it's noisy, but personally I don't see it as a problem as it 
>>> always comes before the func/var/let keyword, generics and function name, 
>>> so it's not like it's near anything where the (minor) noise reduces 
>>> readability.
>>> 
>>> But yeah, having used the new fileprivate for a little while I just don't 
>>> like it; it may partly come down to the fact that I use fileprivate a lot 
>>> more than I use regular private. If we were to adopt the above scheme I 
>>> would recommend that private(file) be the default for use of the plain 
>>> private keyword, unless we gain the ability to specify private(type) (i.e- 
>>> protected in most other languages), as private(scope) seems like it's the 
>>> less common, at least in my experience.
>>> ___
>>> 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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] private & fileprivate

[Xiaodi Wu via swift-evolution]

While no topic is formally off the table, to revisit a topic requires fresh
insight. `private(file)` was suggested at the time and rejected in favor of
`fileprivate`, and we really don't need another rehash of how much each
person likes one or the other.
On Fri, Oct 7, 2016 at 09:02 Adriano Ferreira via swift-evolution <
swift-evolution@swift.org> wrote:

> +1
>
> I would also rather have:
>
> private(scope)
> private(file)
> private(module)
> etc…
>
> — A
>
> On Oct 7, 2016, at 4:24 AM, Haravikk via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On 7 Oct 2016, at 07:39, David Hart via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hello community,
>
> From all the proposals which has gone into Swift 3, *[SE-0025] Scoped
> Access Level* is the only one I’m having second thoughts about. Before
> launching a discussion around it, I’m curious to know if it's worth
> discussing it or if the “ship has sailed”. As the plan is to allow future
> versions of Swift to break source-compatibility in certain rare scenarios,
> perhaps we have a chance to reconsider certain proposals?
>
> Regards,
> David.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> What in particular don't you like about it?
>
> Personally I still don't like the use of fileprivate as the keyword, I was
> very much in favour of a bracketed system like:
>
> private(scope) Current private (I think, it doesn't appear to be
> equivalent to protected in other languages anyway so I wouldn't call it
> type).
> private(file) Current fileprivate
> private(module) Current internal/default when omitted
> public Current public
>
> I favour this because it groups all restrictive access levels under
> private (since they're all some form of private) with an optional modifier
> that's explicit about what it's for. Also, it would have scope to move
> things like final into a modifier too, so you might declare a method as
> public(final), or public(open) if that's implemented later and so-on. Just
> seems like a generally more flexible setup that also reduces the number of
> keywords required.
>
> Some may feel it's noisy, but personally I don't see it as a problem as it
> always comes before the func/var/let keyword, generics and function name,
> so it's not like it's near anything where the (minor) noise reduces
> readability.
>
> But yeah, having used the new fileprivate for a little while I just don't
> like it; it may partly come down to the fact that I use fileprivate a lot
> more than I use regular private. If we were to adopt the above scheme I
> would recommend that private(file) be the default for use of the plain
> private keyword, unless we gain the ability to specify private(type) (i.e-
> protected in most other languages), as private(scope) seems like it's the
> less common, at least in my experience.
> ___
> 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

Re: [swift-evolution] private & fileprivate

[Adrian Zubarev via swift-evolution]

Even if these access modifier names seem to make sense, I don’t really see the 
need of the reconsideration here.

private(scope)  == private
private(file)   == fileprivate
private(module) == internal
Lhs does add more noise, and if I had to tell, fileprivate actually reads well 
and better than private(file).

Which problem isn’t solved here yet? I might be blind and don’t read between 
the lines.



-- 
Adrian Zubarev
Sent with Airmail

Am 7. Oktober 2016 um 16:03:07, Adriano Ferreira via swift-evolution 
(swift-evolution@swift.org) schrieb:

+1

I would also rather have:

private(scope)
private(file)
private(module)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] private & fileprivate

[Adriano Ferreira via swift-evolution]

+1

I would also rather have:

private(scope)
private(file)
private(module)
etc…

— A

> On Oct 7, 2016, at 4:24 AM, Haravikk via swift-evolution 
>  wrote:
> 
> 
>> On 7 Oct 2016, at 07:39, David Hart via swift-evolution 
>> > wrote:
>> 
>> Hello community,
>> 
>> From all the proposals which has gone into Swift 3, [SE-0025] Scoped Access 
>> Level is the only one I’m having second thoughts about. Before launching a 
>> discussion around it, I’m curious to know if it's worth discussing it or if 
>> the “ship has sailed”. As the plan is to allow future versions of Swift to 
>> break source-compatibility in certain rare scenarios, perhaps we have a 
>> chance to reconsider certain proposals?
>> 
>> Regards,
>> David.
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> What in particular don't you like about it?
> 
> Personally I still don't like the use of fileprivate as the keyword, I was 
> very much in favour of a bracketed system like:
> 
>   private(scope)  Current private (I think, it doesn't appear to 
> be equivalent to protected in other languages anyway so I wouldn't call it 
> type).
>   private(file)   Current fileprivate
>   private(module) Current internal/default when omitted
>   public  Current public
> 
> I favour this because it groups all restrictive access levels under private 
> (since they're all some form of private) with an optional modifier that's 
> explicit about what it's for. Also, it would have scope to move things like 
> final into a modifier too, so you might declare a method as public(final), or 
> public(open) if that's implemented later and so-on. Just seems like a 
> generally more flexible setup that also reduces the number of keywords 
> required.
> 
> Some may feel it's noisy, but personally I don't see it as a problem as it 
> always comes before the func/var/let keyword, generics and function name, so 
> it's not like it's near anything where the (minor) noise reduces readability.
> 
> But yeah, having used the new fileprivate for a little while I just don't 
> like it; it may partly come down to the fact that I use fileprivate a lot 
> more than I use regular private. If we were to adopt the above scheme I would 
> recommend that private(file) be the default for use of the plain private 
> keyword, unless we gain the ability to specify private(type) (i.e- protected 
> in most other languages), as private(scope) seems like it's the less common, 
> at least in my experience.
> ___
> 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

Re: [swift-evolution] private & fileprivate

[Charles Constant via swift-evolution]

I actually prefer "fileprivate" to the alternatives, but imo using the word
"private" is a bad choice for this, since it's basically a relative term.
If we're going with parens "visibility(file)" makes more sense to me.



On Fri, Oct 7, 2016 at 5:00 AM, Georgios Moschovitis via swift-evolution <
swift-evolution@swift.org> wrote:

> > FWIW, I fully agree with you and I do believe your suggestion just much
> > ...
> > 'moduleprivate'.. but these are just ugly(just like fileprivate ;-) )
>
> +1
>
> I would also much prefer
>
> private(scope)
> private(file)
> private(module)
> etc...
> ___
> 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

Re: [swift-evolution] private & fileprivate

[Haravikk via swift-evolution]

> On 7 Oct 2016, at 12:11, Jay Abbott  wrote:
> 
> I agree that the keywords could be improved, but private(file) access should 
> not be what 'private' means by itself. If I put just 'private' in front of 
> something I really mean it should be private to this scope, the most private. 
> I also think the more common use-case would be private(scope) over 
> private(file), you might find if you refactor a bit that a lot of your 
> fileprivate can become private or instead - it's possible that fileprivate is 
> encouraging you to put things into one file when they should be in multiple 
> files with a better defined 'internal' API.
> 
> I like the *concept* that 'private' is the most private and then it can be 
> relaxed by modifiers (file) (module) (perhaps-other-stuff), but I'm not 
> convinced that 'private' is really an appropriate word for something that is 
> accessible anywhere within a module. Though I agree that 'internal' doesn't 
> really mean much to someone learning the language, and suffers the exact same 
> problem (internal to what?) whereas private(module) does express that a bit 
> better.

Yeah I'm a bit undecided on that point myself; like I say I'd really prefer 
something like private(type) to be the default for my own use-case, but not 
only do we not have that it probably wouldn't suit everyone anyway, I think 
it's just more that my habit is to implement by extension within the same file. 
With that in mind maybe scope is the better default for it as you say.

I'm not sure what the OP really wanted to raise on the subject, but if there's 
interest for this style of access modifier and it's in-scope for Swift 4 then I 
could do a proposal for it as a specific request.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] private & fileprivate

[Georgios Moschovitis via swift-evolution]

> FWIW, I fully agree with you and I do believe your suggestion just much
> ...
> 'moduleprivate'.. but these are just ugly(just like fileprivate ;-) )

+1

I would also much prefer 

private(scope)
private(file)
private(module)
etc...
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] private & fileprivate

[Jay Abbott via swift-evolution]

I agree that the keywords could be improved, but private(file) access
should not be what 'private' means by itself. If I put just 'private' in
front of something I really mean it should be private to this scope, the
most private. I also think the more common use-case would be private(scope)
over private(file), you might find if you refactor a bit that a lot of your
fileprivate can become private or instead - it's possible that fileprivate
is encouraging you to put things into one file when they should be in
multiple files with a better defined 'internal' API.

I like the *concept* that 'private' is the most private and then it can be
relaxed by modifiers (file) (module) (perhaps-other-stuff), but I'm not
convinced that 'private' is really an appropriate word for something that
is accessible anywhere within a module. Though I agree that 'internal'
doesn't really mean much to someone learning the language, and suffers the
exact same problem (internal to what?) whereas private(module) does express
that a bit better.

On Fri, 7 Oct 2016 at 09:26 Haravikk via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On 7 Oct 2016, at 07:39, David Hart via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hello community,
>
> From all the proposals which has gone into Swift 3, *[SE-0025] Scoped
> Access Level* is the only one I’m having second thoughts about. Before
> launching a discussion around it, I’m curious to know if it's worth
> discussing it or if the “ship has sailed”. As the plan is to allow future
> versions of Swift to break source-compatibility in certain rare scenarios,
> perhaps we have a chance to reconsider certain proposals?
>
> Regards,
> David.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> What in particular don't you like about it?
>
> Personally I still don't like the use of fileprivate as the keyword, I was
> very much in favour of a bracketed system like:
>
> private(scope) Current private (I think, it doesn't appear to be
> equivalent to protected in other languages anyway so I wouldn't call it
> type).
> private(file) Current fileprivate
> private(module) Current internal/default when omitted
> public Current public
>
> I favour this because it groups all restrictive access levels under
> private (since they're all some form of private) with an optional modifier
> that's explicit about what it's for. Also, it would have scope to move
> things like final into a modifier too, so you might declare a method as
> public(final), or public(open) if that's implemented later and so-on. Just
> seems like a generally more flexible setup that also reduces the number of
> keywords required.
>
> Some may feel it's noisy, but personally I don't see it as a problem as it
> always comes before the func/var/let keyword, generics and function name,
> so it's not like it's near anything where the (minor) noise reduces
> readability.
>
> But yeah, having used the new fileprivate for a little while I just don't
> like it; it may partly come down to the fact that I use fileprivate a lot
> more than I use regular private. If we were to adopt the above scheme I
> would recommend that private(file) be the default for use of the plain
> private keyword, unless we gain the ability to specify private(type) (i.e-
> protected in most other languages), as private(scope) seems like it's the
> less common, at least in my experience.
> ___
> 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

Re: [swift-evolution] private & fileprivate

[Vladimir.S via swift-evolution]

On 07.10.2016 11:24, Haravikk via swift-evolution wrote:



On 7 Oct 2016, at 07:39, David Hart via swift-evolution
> wrote:

Hello community,

From all the proposals which has gone into Swift 3, *[SE-0025] Scoped
Access Level* is the only one I’m having second thoughts about. Before
launching a discussion around it, I’m curious to know if it's worth
discussing it or if the “ship has sailed”. As the plan is to allow future
versions of Swift to break source-compatibility in certain rare
scenarios, perhaps we have a chance to reconsider certain proposals?

Regards,
David.
___
swift-evolution mailing list
swift-evolution@swift.org 
https://lists.swift.org/mailman/listinfo/swift-evolution


What in particular don't you like about it?

Personally I still don't like the use of fileprivate as the keyword, I was
very much in favour of a bracketed system like:


FWIW, I fully agree with you and I do believe your suggestion just much 
better than current status quo. It is much clearer what private(module) 
means than 'internal' and private(scope) than just 'private', private(file) 
is 1000% better than fileprivate ;-). Currently IMO names are not 
consistent : if we have 'fileprivate', then we need 'scopeprivate' and 
'moduleprivate'.. but these are just ugly(just like fileprivate ;-) )

IMO



private(scope)Current private (I think, it doesn't appear to be equivalent
to protected in other languages anyway so I wouldn't call it type).
private(file)Current fileprivate
private(module)Current internal/default when omitted
publicCurrent public

I favour this because it groups all restrictive access levels under private
(since they're all some form of private) with an optional modifier that's
explicit about what it's for. Also, it would have scope to move things like
final into a modifier too, so you might declare a method as public(final),
or public(open) if that's implemented later and so-on. Just seems like a
generally more flexible setup that also reduces the number of keywords
required.

Some may feel it's noisy, but personally I don't see it as a problem as it
always comes before the func/var/let keyword, generics and function name,
so it's not like it's near anything where the (minor) noise reduces
readability.

But yeah, having used the new fileprivate for a little while I just don't
like it; it may partly come down to the fact that I use fileprivate a lot
more than I use regular private. If we were to adopt the above scheme I
would recommend that private(file) be the default for use of the plain
private keyword, unless we gain the ability to specify private(type) (i.e-
protected in most other languages), as private(scope) seems like it's the
less common, at least in my experience.


___
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

Re: [swift-evolution] private & fileprivate

[Haravikk via swift-evolution]

> On 7 Oct 2016, at 07:39, David Hart via swift-evolution 
>  wrote:
> 
> Hello community,
> 
> From all the proposals which has gone into Swift 3, [SE-0025] Scoped Access 
> Level is the only one I’m having second thoughts about. Before launching a 
> discussion around it, I’m curious to know if it's worth discussing it or if 
> the “ship has sailed”. As the plan is to allow future versions of Swift to 
> break source-compatibility in certain rare scenarios, perhaps we have a 
> chance to reconsider certain proposals?
> 
> Regards,
> David.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

What in particular don't you like about it?

Personally I still don't like the use of fileprivate as the keyword, I was very 
much in favour of a bracketed system like:

private(scope)  Current private (I think, it doesn't appear to 
be equivalent to protected in other languages anyway so I wouldn't call it 
type).
private(file)   Current fileprivate
private(module) Current internal/default when omitted
public  Current public

I favour this because it groups all restrictive access levels under private 
(since they're all some form of private) with an optional modifier that's 
explicit about what it's for. Also, it would have scope to move things like 
final into a modifier too, so you might declare a method as public(final), or 
public(open) if that's implemented later and so-on. Just seems like a generally 
more flexible setup that also reduces the number of keywords required.

Some may feel it's noisy, but personally I don't see it as a problem as it 
always comes before the func/var/let keyword, generics and function name, so 
it's not like it's near anything where the (minor) noise reduces readability.

But yeah, having used the new fileprivate for a little while I just don't like 
it; it may partly come down to the fact that I use fileprivate a lot more than 
I use regular private. If we were to adopt the above scheme I would recommend 
that private(file) be the default for use of the plain private keyword, unless 
we gain the ability to specify private(type) (i.e- protected in most other 
languages), as private(scope) seems like it's the less common, at least in my 
experience.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] private & fileprivate

[Rien via swift-evolution]

Do language ships ever sail?

New POV’s should always be welcome.

Just spit it out…

Rien.



> On 07 Oct 2016, at 08:39, David Hart via swift-evolution 
>  wrote:
> 
> Hello community,
> 
> From all the proposals which has gone into Swift 3, [SE-0025] Scoped Access 
> Level is the only one I’m having second thoughts about. Before launching a 
> discussion around it, I’m curious to know if it's worth discussing it or if 
> the “ship has sailed”. As the plan is to allow future versions of Swift to 
> break source-compatibility in certain rare scenarios, perhaps we have a 
> chance to reconsider certain proposals?
> 
> Regards,
> David.
> ___
> 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] private & fileprivate

[David Hart via swift-evolution]

Hello community,

>From all the proposals which has gone into Swift 3, [SE-0025] Scoped Access 
>Level is the only one I’m having second thoughts about. Before launching a 
>discussion around it, I’m curious to know if it's worth discussing it or if 
>the “ship has sailed”. As the plan is to allow future versions of Swift to 
>break source-compatibility in certain rare scenarios, perhaps we have a chance 
>to reconsider certain proposals?

Regards,
David.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution