Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

How about private(world), public(module), internal(file)? :-) Slava > On Mar 25, 2017, at 4:15 PM, Adrian Zubarev via swift-evolution > wrote: > > Please do not start a debate about `private(module)` which is equavalent to > `internal`, otherwise you could equally

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 23, 2017, at 18:35, Matthew Johnson via swift-evolution > wrote: > > On Mar 23, 2017, at 8:27 PM, Drew Crawford > wrote: > >> >> The obvious example would be Rust. Rust has exactly two

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

This would address my concerns. rob On Fri, Mar 24, 2017 at 10:27 AM, Ross O'Brien via swift-evolution < swift-evolution@swift.org> wrote: > We should be clear about this, because it seems to me that this is the > source of the 'cognitive load' problem: > > Following Alternative 3, > private

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

This and the reasons Drew laid out, are why I'm -1. > On Mar 23, 2017, at 19:48, Charles Srstka via swift-evolution > wrote: > >> On Mar 23, 2017, at 8:35 PM, Matthew Johnson via swift-evolution >> wrote: >> >> On Mar 23, 2017, at 8:27

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

On March 24, 2017 at 10:17:57 AM, Matt Whiteside (mwhiteside@gmail.com) wrote: In other words, this use case seems fairly distant from what was intended for private vs fileprivate. The "not public API" motivation is directly in view for private/fileprivate.   Promoting this API to a

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 23, 2017, at 00:10, Drew Crawford via swift-evolution > wrote: > >> This fails to convince me. I had similar thoughts. > I understand that, but not why. > > I can't go into detail in public, but I can say that we did a postmortem on a > large lost sale

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

On 24.03.2017 17:27, Ross O'Brien wrote: We should be clear about this, because it seems to me that this is the source of the 'cognitive load' problem: Following Alternative 3, private properties in scopes, would become "scoped". fileprivate properties in or out of scopes would become

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

We should be clear about this, because it seems to me that this is the source of the 'cognitive load' problem: Following Alternative 3, private properties in scopes, would become "scoped". fileprivate properties in or out of scopes would become "private". private types, such as protocols,

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

After reading the discussions it seems to me that renaming private -> scoped and fileprivate -> private might keep both sides happy. > On Mar 24, 2017, at 9:06 AM, Vladimir.S via swift-evolution > wrote: > >> On 24.03.2017 11:47, Jonathan Hull via swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

On 24.03.2017 11:47, Jonathan Hull via swift-evolution wrote: Nevin had a fantastic proposal for submodules which changed private to mean “private to the submodule”, where each file was implicitly a submodule unless you declared otherwise. Simple and elegant. Currently I don't see how

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> What is your evaluation of the proposal? A very reluctant -1. “Reluctant" because I suspect that we won’t get another chance to revisit this, and I *do* think it’s broken. I’m in the camp that believes the result we got out of SE-25 was not helpful to the evolution of Swift, and I would like

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

Sent from my iPad > On Mar 23, 2017, at 9:48 PM, Charles Srstka wrote: > >> On Mar 23, 2017, at 8:35 PM, Matthew Johnson via swift-evolution >> wrote: >> >> On Mar 23, 2017, at 8:27 PM, Drew Crawford wrote: >>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

I also add my voice on the -1 side and fully agree with Drew’s reasoning. `private` and `fileprivate` have a very distinct use in the code I write and in my opinion both carry their weight. I’m not opposed to renaming or changing access modifiers, but I don’t see the need for it now. I agree

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

Nevin had a fantastic proposal for submodules which changed private to mean “private to the submodule”, where each file was implicitly a submodule unless you declared otherwise. Simple and elegant. > On Mar 23, 2017, at 6:27 PM, Drew Crawford via swift-evolution >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

Sent from my iPhone > On 24 Mar 2017, at 05:36, Xiaodi Wu via swift-evolution > wrote: > > I agree with everything you wrote here. And it is for that reason that I > would expect that any future proposal for submodules should be judged in no > small part on its

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

I agree with everything you wrote here. And it is for that reason that I would expect that any future proposal for submodules should be judged in no small part on its _not_ changing circumstances surrounding access modifiers, such that no further proposals to revisit this topic will come up. It's

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

Or, since many designs for submodules are possible... confident that there will be a good design for submodules We lack any real information on what Swift designs are possible.  We can look to other languages for inspiration but they cannot be transplanted wholesale into Swift from a technical,

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

Big -1 from me. While I don't like fileprivate at all, removing private as it presently exists is not the answer. For details on my thoughts, please refer to Drew Crawford's excellent responses to this proposal; he states it far better than I ever could :) -- Gwynne Raskind > On Mar 20, 2017,

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

Or, since many designs for submodules are possible, we can proceed to make the best decision *now* with respect to access levels, confident that there will be a good design for submodules whether or not there exist both scoped and file-based private access. That is to say, any future submodule

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 23, 2017, at 8:35 PM, Matthew Johnson via swift-evolution > wrote: > > On Mar 23, 2017, at 8:27 PM, Drew Crawford > wrote: > >> >> >> >> Sent from my iPhone >> On Mar 23, 2017, at 6:41 PM, David

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

Sent from my iPad > On Mar 23, 2017, at 8:27 PM, Drew Crawford wrote: > > > > > Sent from my iPhone > On Mar 23, 2017, at 6:41 PM, David Hart wrote: > >> I have difficulties imagining a submodule proposal that could allow us to >> eliminate

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

Sent from my iPhone > On Mar 23, 2017, at 6:41 PM, David Hart wrote: > > I have difficulties imagining a submodule proposal that could allow us to > eliminate fileprivate. Care to give an example? The obvious example would be Rust. Rust has exactly two visibilities, and

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> But with static linking, your user wouldn’t have to drag 4 .a libraries but > only one, which contains all libraries statically linked together. Static linking is unrelated to merging modules. We can statically link libraries on Linux right now, this does not reduce the files on disk or

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On 23 Mar 2017, at 21:49, Drew Crawford wrote: > >> I'm curious to hear what issue your client had with you using many >> frameworks that static linking doesn't solve. > > The issue here is the number of frameworks that the user drags and drops into > Xcode. Most

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On 23 Mar 2017, at 20:18, Matthew Johnson wrote: > > >> On Mar 23, 2017, at 2:02 PM, David Hart via swift-evolution >> > wrote: >> >> >> >> On 23 Mar 2017, at 16:49, Drew Crawford

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

On March 23, 2017 at 12:32:38 PM, Brent Royal-Gordon (br...@architechies.com) wrote: To what extent could your need for safety be satisfied by (a) giving the property a long, unique name like `unsafeUnsynchronizedT`, and (b) writing a very small unit test/shell script/Perl script which

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

I'm curious to hear what issue your client had with you using many frameworks that static linking doesn't solve. The issue here is the number of frameworks that the user drags and drops into Xcode.  Most libraries ship as a single framework, see this page for a typical example of what the

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 23, 2017, at 2:02 PM, David Hart via swift-evolution > wrote: > > > > On 23 Mar 2017, at 16:49, Drew Crawford > wrote: > >> >> >> >> On March 23, 2017 at 2:22:20 AM, David Hart

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On 23 Mar 2017, at 16:49, Drew Crawford wrote: > > > > >> On March 23, 2017 at 2:22:20 AM, David Hart (da...@hartbit.com) wrote: >> >> > We will get static linking at some point in the near future. > > Static linking does not fix this issue. Just change

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

To what extent could your need for safety be satisfied by (a) giving the property a long, unique name like `unsafeUnsynchronizedT`, and (b) writing a very small unit test/shell script/Perl script which makes sure references to that very unique name only appear between the two "MARK:" comments?

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> I can't go into detail in public, but I can say that we did a postmortem on a > large lost sale and the customer specifically cited the number of frameworks > in our product as an integration barrier for them. Most iOS SDKs are > distributed as a single framework and so with that backdrop

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 23, 2017, at 10:51 AM, Andrey Fidrya via swift-evolution > wrote: > >> On 23 Mar 2017, at 05:18, Nevin Brackett-Rozinsky via swift-evolution >> wrote: >> I strongly prefer that “private” should mean “visible in the current file”.

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On 23 Mar 2017, at 05:18, Nevin Brackett-Rozinsky via swift-evolution > wrote: > I strongly prefer that “private” should mean “visible in the current file”. > I am ambivalent between eliminating the scoped access level or renaming it > “scoped”, as long as “private”

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

On March 23, 2017 at 2:22:20 AM, David Hart (da...@hartbit.com) wrote: > We will get static linking at some point in the near future. Static linking does not fix this issue. Just change "framework" to ".a". > If we wait until we get submodules, we won't be able to revisit. This is > probably

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

It has been expressed in various ways "does anybody actually use scoped visibility in the wild" and "what real benefit does it provide to production code". The below file or some estranged stepchild of it appears at least 5 repositories (that I know of; this is practically a samizdat around

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

I strongly prefer that “private” should mean “visible in the current file”. I am ambivalent between eliminating the scoped access level or renaming it “scoped”, as long as “private” once more denotes file-level visibility. Nevin ___ swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

+1 What is "current private" can be replicated with the new behavior, use of files, and use of modules. On Wed, Mar 22, 2017 at 8:59 PM, Jordan Rose via swift-evolution < swift-evolution@swift.org> wrote: > > On Mar 21, 2017, at 15:26, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 21, 2017, at 15:26, Xiaodi Wu via swift-evolution > wrote: > > The kicker is, _it also doesn't work_. Try, for instance: > > ``` > struct Foo { > private var bar: Int { return 42 } > } > > extension Foo { > private var bar: Int { return 43 } > } > ```

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

On Wed, Mar 22, 2017, at 01:58 PM, Kevin Ballard wrote: > On Mon, Mar 20, 2017, at 04:54 PM, Douglas Gregor wrote: >> * What is your evaluation of the proposal? > > Huge -1, and I agree strongly with Drew Crockford's emails on > this topic. My apologies, Drew. It's Drew Crawford. -Kevin

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

On Mon, Mar 20, 2017, at 04:54 PM, Douglas Gregor wrote: > * What is your evaluation of the proposal? Huge -1, and I agree strongly with Drew Crockford's emails on this topic. -Kevin Ballard ___ swift-evolution mailing list swift-evolution@swift.org

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

- What is your evaluation of the proposal? +1 I'm generally a proponent of scoped access control and have been torn over this proposal. What finally pushed me over the edge has been the time I've taken to review others code. I've got a team of about 32 iOS developers and their code shows a

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On 22 Mar 2017, at 03:16, Xiaodi Wu wrote: > >> On Tue, Mar 21, 2017 at 9:38 PM, Matthew Johnson wrote: >> >>> On Mar 21, 2017, at 9:28 PM, Xiaodi Wu wrote: >>> >>> And couldn't this be enforced by a linter feature that warns if a private >>> member beginning with _ is accessed outside of

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

On Tue, Mar 21, 2017 at 10:51 PM, Charles Srstka via swift-evolution < swift-evolution@swift.org> wrote: > > The bug *does not affect what people use private for,* and so it *does not > affect anything in real-world use.* It’s less “the Finder makes your files > disappear on a regular basis” and

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 21, 2017, at 10:42 PM, Xiaodi Wu wrote: > > On Tue, Mar 21, 2017 at 10:36 PM, Charles Srstka > wrote: >> On Mar 21, 2017, at 10:15 PM, Xiaodi Wu > >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

On Tue, Mar 21, 2017 at 10:36 PM, Charles Srstka wrote: > On Mar 21, 2017, at 10:15 PM, Xiaodi Wu wrote: > > > On Tue, Mar 21, 2017 at 9:40 PM, Charles Srstka > wrote: > >> On Mar 21, 2017, at 9:17 PM, Xiaodi Wu

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 21, 2017, at 10:15 PM, Xiaodi Wu wrote: > > On Tue, Mar 21, 2017 at 9:40 PM, Charles Srstka > wrote: >> On Mar 21, 2017, at 9:17 PM, Xiaodi Wu > > wrote:

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

On Tue, Mar 21, 2017 at 9:38 PM, Matthew Johnson wrote: > > On Mar 21, 2017, at 9:28 PM, Xiaodi Wu wrote: > > On Tue, Mar 21, 2017 at 8:31 PM, Matthew Johnson > wrote: > >> >> >> Sent from my iPad >> >> On Mar 21, 2017, at

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

On Tue, Mar 21, 2017 at 9:40 PM, Charles Srstka wrote: > On Mar 21, 2017, at 9:17 PM, Xiaodi Wu wrote: > > > On Tue, Mar 21, 2017 at 8:31 PM, Charles Srstka > wrote: > >> >> On Mar 21, 2017, at 8:15 PM, Xiaodi Wu

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 21, 2017, at 10:02 PM, Xiaodi Wu wrote: > > On Tue, Mar 21, 2017 at 9:32 PM, Matthew Johnson > wrote: > >> On Mar 21, 2017, at 9:17 PM, Xiaodi Wu via swift-evolution >>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

On Tue, Mar 21, 2017 at 9:32 PM, Matthew Johnson wrote: > > On Mar 21, 2017, at 9:17 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On Tue, Mar 21, 2017 at 8:31 PM, Charles Srstka > wrote: > >> >> On Mar 21, 2017, at

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

On Tue, Mar 21, 2017 at 9:31 PM, Drew Crawford wrote: > > > > On March 21, 2017 at 9:18:00 PM, Xiaodi Wu (xiaodi...@gmail.com) wrote: > > You're not hearing the argument. No one "accidentally" included this > design as part of SE-0025; it's sentence number one. > > To

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 21, 2017, at 9:17 PM, Xiaodi Wu wrote: > > On Tue, Mar 21, 2017 at 8:31 PM, Charles Srstka > wrote: > >> On Mar 21, 2017, at 8:15 PM, Xiaodi Wu > >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 21, 2017, at 9:17 PM, Xiaodi Wu via swift-evolution > wrote: > > On Tue, Mar 21, 2017 at 8:31 PM, Charles Srstka > wrote: > >> On Mar 21, 2017, at 8:15 PM, Xiaodi Wu >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

On March 21, 2017 at 9:18:00 PM, Xiaodi Wu (xiaodi...@gmail.com) wrote: You're not hearing the argument. No one "accidentally" included this design as part of SE-0025; it's sentence number one.  To quote this in context: Scoped access level allows hiding implementation details of a class or

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

On Tue, Mar 21, 2017 at 8:31 PM, Matthew Johnson wrote: > > > Sent from my iPad > > On Mar 21, 2017, at 7:40 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On Tue, Mar 21, 2017 at 6:44 PM, Drew Crawford > wrote: > >>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

On Tue, Mar 21, 2017 at 9:15 PM, Drew Crawford via swift-evolution < swift-evolution@swift.org> wrote: > > > > On March 21, 2017 at 7:45:22 PM, Zach Waldowski via swift-evolution ( > swift-evolution@swift.org) wrote: > > Swift should only impose a preference when it's important to the speed, >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

On Tue, Mar 21, 2017 at 8:31 PM, Charles Srstka wrote: > > On Mar 21, 2017, at 8:15 PM, Xiaodi Wu wrote: > > On Tue, Mar 21, 2017 at 8:00 PM, Charles Srstka > wrote: > >> On Mar 21, 2017, at 7:49 PM, Xiaodi Wu

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

On March 21, 2017 at 7:45:22 PM, Zach Waldowski via swift-evolution (swift-evolution@swift.org) wrote: Swift should only impose a preference when it's important to the speed, functionality, and safety of the language. I have yet to be convinced that there's a benefit to a scoped access

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

On Tue, Mar 21, 2017 at 6:44 PM, Drew Crawford via swift-evolution < swift-evolution@swift.org> wrote: > A core team member (I'm blanking on who) has pointed out that, in the end, > the only necessary access modifiers are public and not public (spelled > "internal" in Swift). > > > It is not

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 21, 2017, at 8:15 PM, Xiaodi Wu wrote: > > On Tue, Mar 21, 2017 at 8:00 PM, Charles Srstka > wrote: >> On Mar 21, 2017, at 7:49 PM, Xiaodi Wu > > wrote:

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

Sent from my iPad > On Mar 21, 2017, at 7:40 PM, Xiaodi Wu via swift-evolution > wrote: > >> On Tue, Mar 21, 2017 at 6:44 PM, Drew Crawford >> wrote: I am confused by this response. An argument in _support_ of new `private` was

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

On Tue, Mar 21, 2017 at 8:00 PM, Charles Srstka wrote: > On Mar 21, 2017, at 7:49 PM, Xiaodi Wu wrote: > > > On Tue, Mar 21, 2017 at 6:46 PM, Charles Srstka > wrote: > >> On Mar 21, 2017, at 5:26 PM, Xiaodi Wu via

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 21, 2017, at 7:49 PM, Xiaodi Wu wrote: > > On Tue, Mar 21, 2017 at 6:46 PM, Charles Srstka > wrote: >> On Mar 21, 2017, at 5:26 PM, Xiaodi Wu via swift-evolution >>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

On Tue, Mar 21, 2017 at 6:46 PM, Charles Srstka wrote: > On Mar 21, 2017, at 5:26 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > > So, if four/five access modifiers are too many, which one is carrying the > least weight? Which one could be

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

On Tue, Mar 21, 2017, at 07:44 PM, Drew Crawford via swift-evolution wrote: >> When new `private` and `fileprivate` were shipped, there were >> numerous questions asked by users on forums such as Stack Overflow > > And before they were shipped, there were people asking for a scoped > modifier.

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

On Tue, Mar 21, 2017 at 6:44 PM, Drew Crawford wrote: > I am confused by this response. An argument in _support_ of new `private` > was that it is more in line with expectations of users coming from other > languages. In other some cases, such an argument might have its

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 21, 2017, at 5:26 PM, Xiaodi Wu via swift-evolution > wrote: > > So, if four/five access modifiers are too many, which one is carrying the > least weight? Which one could be removed to simplify the scheme while > maintaining the most expressiveness? Which

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

I am confused by this response. An argument in _support_ of new `private` was that it is more in line with expectations of users coming from other languages. In other some cases, such an argument might have its place. However, as others have pointed out on this list, those other languages don't

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

Sent from my iPhone > On 21 Mar 2017, at 22:49, Charles Srstka via swift-evolution > wrote: > >> On Mar 21, 2017, at 5:43 PM, David Hart via swift-evolution >> wrote: >> >> That’s why protected (a feature) is on the commonly rejected

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 21, 2017, at 5:43 PM, David Hart via swift-evolution > wrote: > > That’s why protected (a feature) is on the commonly rejected proposals list Unless you’re referring to a different “commonly rejected proposals” list than the one below, this does not appear

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On 21 Mar 2017, at 21:59, Drew Crawford wrote: > >> The arguments for the revert are in the proposal and in the discussions in >> this thread. > > > What is in the proposal and this thread are a set of opinions, e.g. > > * "the access level change of SE-0025 was

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

On Tue, Mar 21, 2017 at 3:59 PM, Drew Crawford via swift-evolution < swift-evolution@swift.org> wrote: > The arguments for the revert are in the proposal and in the discussions > in this thread. > > > What is in the proposal and this thread are a set of opinions, e.g. > > * "the access level

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

Sent from my iPhone > On Mar 21, 2017, at 4:48 PM, Jose Cheyo Jimenez wrote: > > >>> On Mar 21, 2017, at 2:33 PM, Matthew Johnson wrote: >>> >>> On Mar 21, 2017, at 4:26 PM, Jose Cheyo Jimenez wrote:

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 21, 2017, at 2:33 PM, Matthew Johnson wrote: > >> >> On Mar 21, 2017, at 4:26 PM, Jose Cheyo Jimenez > > wrote: >> >> >>> On Mar 21, 2017, at 11:54 AM, Matthew Johnson via swift-evolution >>>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 21, 2017, at 4:26 PM, Jose Cheyo Jimenez wrote: > > >> On Mar 21, 2017, at 11:54 AM, Matthew Johnson via swift-evolution >> > wrote: >> >> >>> On Mar 21, 2017, at 1:41 PM, David Hart via

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 21, 2017, at 11:54 AM, Matthew Johnson via swift-evolution > wrote: > > >> On Mar 21, 2017, at 1:41 PM, David Hart via swift-evolution >> > wrote: >> >> >> >> >> >> Sent from my iPhone >> On

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

 The arguments for the revert are in the proposal and in the discussions in this thread. What is in the proposal and this thread are a set of opinions, e.g. * "the access level change of SE-0025 was met with dissatisfaction by a substantial proportion of the general Swift community." * "Those

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

Sent from my iPhone > On 21 Mar 2017, at 18:41, David Hart via swift-evolution > wrote: > > > > > > Sent from my iPhone > On 21 Mar 2017, at 16:57, Drew Crawford wrote: > >> >> >>> > I’m not arguing that it is less or more than a

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

Sent from my iPhone > On 21 Mar 2017, at 15:57, Drew Crawford via swift-evolution > wrote: > > > >> > I’m not arguing that it is less or more than a majority. I’m just saying >> > that we’ve seen a lot of talk against the original change. > > This proposal asks

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> • What is your evaluation of the proposal? Renaming `fileprivate` to `private` makes sense. In my code, I use `fileprivate` and `private` interchangeably, meaning that I write `private` for things that shouldn't be leaked to the whole module and if by chance the compiler complain I'll

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 21, 2017, at 1:41 PM, David Hart via swift-evolution > wrote: > > > > > > Sent from my iPhone > On 21 Mar 2017, at 16:57, Drew Crawford > wrote: > >> >> >>> > I’m not arguing that it is less

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 21, 2017, at 6:43 PM, Jose Cheyo Jimenez wrote: > >> >> On Mar 21, 2017, at 1:10 AM, Charlie Monroe via swift-evolution >> > wrote: >> >> >>> On Mar 21, 2017, at 8:26 AM, Slava Pestov

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

Sent from my iPhone > On 21 Mar 2017, at 16:57, Drew Crawford wrote: > > > >> > I’m not arguing that it is less or more than a majority. I’m just saying >> > that we’ve seen a lot of talk against the original change. > > This proposal asks us to balance the

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 21, 2017, at 1:10 AM, Charlie Monroe via swift-evolution > wrote: > > >> On Mar 21, 2017, at 8:26 AM, Slava Pestov > > wrote: >> >>> >>> On Mar 20, 2017, at 11:07 PM, Charlie Monroe via swift-evolution >>>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

True indeed… but can we agree that this is just an hypothetic example, and no issue that is likely to happen in productive code? Or is this actually taken from one of the projects you measured? Here is the expanded edition which is productive. /**A dummy return value to indicate a method

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

I have a few cases like that in production code with an unthread safe private function shadows a more public function that applies thread safety for external callers, etc. -Shawn On Tue, Mar 21, 2017 at 9:37 AM Tino Heth via swift-evolution < swift-evolution@swift.org> wrote: > > > Fact is, you

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

-1. While I agree generally that access control in swift is not yet perfect, I feel strongly that any further reshaping of access control primitives should wait until a submodule design is in place. To do another zag on this issue at this point seems preliminary, tweaky, and almost capricious

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

- What is your evaluation of the proposal? In general: against. Scope-based access is useful and should not be removed. The fileprivate keyword is long and awkward to say, but unambiguous in purpose. 'Private' is ambiguous, referring to scope-based access inside a scope but file-based access

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

On Mon, Mar 20, 2017 at 7:54 PM Douglas Gregor wrote: > Hello Swift community, > > The review of SE-0159 "Fix Private Access Levels" begins now and runs > through March 27, 2017. The proposal is available here: > > >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 21, 2017, at 10:57 AM, Drew Crawford via swift-evolution > wrote: > > > >> > I’m not arguing that it is less or more than a majority. I’m just saying >> > that we’ve seen a lot of talk against the original change. > > This proposal asks us to balance the

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> I’m not arguing that it is less or more than a majority. I’m just saying that > we’ve seen a lot of talk against the original change. This proposal asks us to balance the convenience of one group (extension-writers) against the existence of another (scoped-access users).  To do that, we

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

On March 21, 2017 at 7:00:32 AM, Tino Heth (2...@gmx.de) wrote: > If private is really more useful, should we remove fileprivate instead? We don’t have to remove any access modifier.  They are all useful. > Fact is, you can replace every occurrence of "private" with "fileprivate", > and your

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 20, 2017, at 9:33 PM, Greg Parker via swift-evolution > wrote: > > >> On Mar 20, 2017, at 4:54 PM, Douglas Gregor > > wrote: >> >> Hello Swift community, >> >> The review of SE-0159 "Fix Private Access

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> Yes. To cite some evidence, here are codebases I actively maintain: > > | codebase | private # | > fileprivate # | ratio | > > ||---|---|---| > > | "M" (proprietary)

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

-1 I second Drew Crawford's opinion. Although I agree with some of the critiques about the current state of access levels in swift, I don't believe that this would be the right way to proceed. On 21 March 2017 at 06:56, Drew Crawford via swift-evolution < swift-evolution@swift.org> wrote: > I

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 20, 2017, at 8:26 PM, Charles Srstka via swift-evolution > wrote: > > the concern with extensions could be easily solved simply by giving > extensions access to private members of the extended type as long as those > extensions are in the same

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

The review of SE-0159 "Fix Private Access Levels" > What is your evaluation of the proposal? Great idea too fiddly and fussy for my liking. Preferred the original meaning of private. > Is the problem being addressed significant enough to warrant a change to > Swift? Probably > Does this

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 21, 2017, at 8:26 AM, Slava Pestov wrote: > >> >> On Mar 20, 2017, at 11:07 PM, Charlie Monroe via swift-evolution >> > wrote: >> >> -1 on this as well for similar reasons. Places where I use fileprivate

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

Forgot to cc. Sent from my iPhone > On 21 Mar 2017, at 07:43, Goffredo Marocchi wrote: > > > Sent from my iPhone > >> On 21 Mar 2017, at 02:33, Greg Parker via swift-evolution >> wrote: >> >> >>> On Mar 20, 2017, at 4:54 PM, Douglas Gregor

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

Sent from my iPhone > On 21 Mar 2017, at 05:48, Charles Srstka via swift-evolution > wrote: > >> On Mar 21, 2017, at 12:11 AM, Xiaodi Wu via swift-evolution >> wrote: >> >> Charles Srstka's added comment, while intriguing, poses a

  1   2   >