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] [Proposal] Foundation Swift Archival & Serialization

Hi Itai, On Tue, Mar 21, 2017 at 1:03 PM Itai Ferber wrote: Hi Colin, Thanks for your comments! Are you talking about Codable synthesis, or encoding in general? Yeah, I meant specifically in the case where things are synthesized automatically. As you point out below, if

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

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] [Proposal] Factory Initializers

This was kind of my point - all current class initializers are allocating. Allowing non-allocating initializers would solve most cases, including factory methods. The last else statement in your example (for a regular case) can definitely return a value from another initializer - e.g.

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

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

-1 on this as well for similar reasons. Places where I use fileprivate (aside from what was automatically migrated by Xcode) can be counted on fingers of one or two hands. I feel that this proposal is reverting something without offering an alternative solution. > On Mar 21, 2017, at 3:33

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

On Tue, Mar 21, 2017 at 12:48 AM, Charles Srstka wrote: > On Mar 21, 2017, at 12:11 AM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > > Charles Srstka's added comment, while intriguing, poses a problem in > argumentation. One of the points

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

+1 > • What is your evaluation of the proposal? Makes the language easier to understand, lowers cognitive load during coding. I also hope this will pave the way for a overhaul of the access level system including modularization. > • Is the problem being addressed significant enough

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

> On Mar 20, 2017, at 4:54 PM, Douglas Gregor via swift-evolution > wrote: > > Proposal link: > >> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md > > • What is your evaluation of the proposal? I'm torn. During

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

> On 21 Mar 2017, at 10:15, Jonathan Hull via swift-evolution > wrote: +1 Big Yes, collect the other stuff on access levels and modules too before implementing anything. > > I wonder if there is a way to basically accept that this is what we want to > do, but

Re: [swift-evolution] Fwd: Re: Smart KeyPaths

> On Mar 20, 2017, at 9:12 PM, Ricardo Parada via swift-evolution > wrote: > > If a character had to be used to denote key paths then I would prefer this > one: > > 1. Type:path.to.value and instance:path.to.value > > I feel like the # screams at me. :-) If I

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

> 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 (aside > from what was automatically migrated by Xcode) can be counted on fingers of > one or two hands. > > I

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

Sent from my iPhone > On 21 Mar 2017, at 07:05, Rien via swift-evolution > wrote: > > +1 > >>• What is your evaluation of the proposal? > > Makes the language easier to understand, lowers cognitive load during coding. Is it really a problem for cognitive load

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

I wonder if there is a way to basically accept that this is what we want to do, but delay implementing it until we have other changes to make to the access system (e.g. submodules) at the same time? If things like that are scoped for Swift 5, then I would say delay implementing this until

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

> On Mar 20, 2017, at 12:31 PM, Itai Ferber wrote: > > I don’t think there’s much of a difference between adding an "optional" > primitive (which has a default implementation in terms of a different > primitive) and simply having that type adopt Codable itself and not be a

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

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

> 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] [Proposal] Factory Initializers

I just have to ask: why should a factory method be part of the language? I have nothing against it, I am just wondering if I am missing something. The way I see it everyone can add a factory initializer if he/she needs it. Why make it part of the language? Regards, Rien Site:

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

> On 21 Mar 2017, at 02:26, Drew Crawford via swift-evolution > wrote: > > I disagree quite strongly with the proposal. > > First, the document draws conclusions without apparent supporting evidence, > e.g. > > > Since the release of Swift 3, the access level

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] [Review] SE-0159: Fix Private Access Levels

> On 21 Mar 2017, at 08:55, Goffredo Marocchi wrote: > > > Sent from my iPhone > >> On 21 Mar 2017, at 07:05, Rien via swift-evolution >> wrote: >> >> +1 >> >>> • What is your evaluation of the proposal? >> >> Makes the language easier to

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 null safety questions

I still like the idea of shared memory, but since without additional threading it can’t have write access inside the new process, I don’t think that it is a solution for a webserver. The main concern was just with developers using these universal exceptions deliberately, along with “inconsistent

[swift-evolution] [Proposal] Add clamp(to:) to the stdlib

​Swift-Evolution, I propose that `clamp(to:)` be added to the standard library as detailed in the proposal written below. There is also an open pull request to the swift-evolution repository open here: https://github.com/apple/swift-evolution/pull/641 The idea was discussed on previous threads

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

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

Hi, > What is your evaluation of the proposal? +1, I’ve experienced the described problem in my projects. > Is the problem being addressed significant enough to warrant a change to > Swift? Yes. > Does this proposal fit well with the feel and direction of Swift? Yes. > If you have used

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

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

> 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] Smart KeyPaths

Sent from my iPad > On Mar 21, 2017, at 8:00 PM, Ben Rimmington wrote: > > Re: > >> On 21 Mar 2017, at 13:16, Matthew Johnson wrote: >> >> I think the language is best served if all unbound members are accessible

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

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 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] [Review] SE-0159: Fix Private Access Levels

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review: What is your evaluation of the proposal? -1 Is

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 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: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 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] Smart KeyPaths

Re: > On 21 Mar 2017, at 13:16, Matthew Johnson wrote: > > I think the language is best served if all unbound members are accessible > using the same syntax. IMO this proposal does the right thing by choosing > consistency with existing

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 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, 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 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 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 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 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 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] Smart KeyPaths

> On Mar 20, 2017, at 4:12 AM, David Hart via swift-evolution > wrote: > > > >> On 20 Mar 2017, at 10:39, Jonathan Hull via swift-evolution >> wrote: >> >> +1. This is my favorite solution so far. >> >> With ‘Person.keypath.name' it

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

 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] [Review] SE-0159: Fix Private Access Levels

Sent from my iPhone > On 21 Mar 2017, at 20:36, Goffredo Marocchi wrote: > > > > Sent from my iPhone > >> On 21 Mar 2017, at 16:23, Davor Jankolija via swift-evolution >> wrote: >> >> >>> What is your evaluation of the proposal? >> >> + 1.

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] [Proposal] Factory Initializers

There are several reasons. It is a very common pattern in ObjC/Cocoa. For example, they allow class clusters (and the protocol equivalent). One of the Apple foundation people replied earlier in this thread that it would allow them to remove several hacks from the foundation overlays, and

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

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

> 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] Smart KeyPaths

> On 21 Mar 2017, at 20:04, David Smith via swift-evolution > wrote: > > >> On Mar 20, 2017, at 4:12 AM, David Hart via swift-evolution >> wrote: >> >> >> >>> On 20 Mar 2017, at 10:39, Jonathan Hull via swift-evolution >>>

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

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

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

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

[swift-evolution] SE-0157: Support recursive constraints on associated types

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0157-recursive-protocol-constraints.md Hello, Swift community. The review of "SE-0157: Support recursive

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: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: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: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] Smart KeyPaths

Sometimes I feel like we need a winning sigil for this, one that would look good, it is not already taken and easy to type in all keyboards. Maybe we'll have to start looking at emojis :-) > On Mar 21, 2017, at 9:13 PM, Matthew Johnson 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: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: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

> 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

> 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] [Proposal] Foundation Swift Archival & Serialization

Hi Colin, Thanks for your comments! Are you talking about `Codable` synthesis, or encoding in general? On 21 Mar 2017, at 8:44, Colin Barrett wrote: Hi Itai, Glad to see these proposal! I'm curious, have you or the other Swift folks thought about how *users* of these new Codable protocols

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 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] [Proposal] Foundation Swift Archival & Serialization

> On Mar 21, 2017, at 11:24 AM, Colin Barrett > wrote: > > I'm not sure I follow. What do you mean "which strategy to use for a given > encoding"? IMO there should be at most one implementation of Coding / > Decoding for a particular type. So the way you'd say "I

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] [Review] SE-0159: Fix Private Access Levels

> What is your evaluation of the proposal? I’m positive towards this proposal in isolation. It’s a step in the right direction. But I also feel that it doesn’t fully address the larger issue around access control. > Is the problem being addressed significant enough to warrant a change to >

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

> 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] [Review] SE-0159: Fix Private Access Levels

- What is your evaluation of the proposal? +0.5, with my preference being Alternative 2 - Is the problem being addressed significant enough to warrant a change to Swift? Yes. Others have pointed out that "the extension problem" could be addressed by giving extensions access to private

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

I'm not sure I follow. What do you mean "which strategy to use for a given encoding"? IMO there should be at most one implementation of Coding / Decoding for a particular type. So the way you'd say "I want to decode a JSON response that implements my blog model" would be, reusing the definition

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

Hi Itai, Glad to see these proposal! I'm curious, have you or the other Swift folks thought about how *users* of these new Codable protocols will interact with resilience domains? What I mean is that what appear to be private or internal identifiers, and thus changeable at will, may actually be

Re: [swift-evolution] [Proposal] Factory Initializers

I believe that this proposal is trying to solve something that can be solved by allowing assignment to self within convenience initializers. Unfortunately, even convenience initializers are allocating which makes it harder to achieve with backward compatibility - though I'm not entirely sure

Re: [swift-evolution] [Proposal] Factory Initializers

Forgive me if that has already been discussed in the email threads prior to the proposal, but what I’m missing from this proposal is a discussion of the problems factory initializers solve (other than the examples at the end) and an explanation of why factory initializers are the right solution

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

On Thu, Mar 16, 2017 at 3:33 PM Itai Ferber via swift-evolution < swift-evolution@swift.org> wrote: > > Here's what I mean: Suppose I have a BlogPost model, and I can both fetch > and post BlogPosts to a cross-platform web service, and store them locally. > But when I fetch and post remotely, I

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

> On Mar 21, 2017, at 11:00 AM, Colin Barrett via swift-evolution > wrote: > > > > On Thu, Mar 16, 2017 at 3:33 PM Itai Ferber via swift-evolution > > wrote: > > Here's what I mean: Suppose I have a

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

> What is your evaluation of the proposal? + 1. Don’t like to admit it but i favored the fileprivate modifier when it was introduced. Alas more experince with Swift has meant that I now very often catch myself changing private to fileprivate if for nothing else then to allow protocol

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

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