Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

I'm not sure wether the review period is actually over (or better say "turned into an internal discussion", as I haven't seen a result yet ;-), but as nobody jumped onto the "something more holistic"-train, I used my free time at the lake for some thinking… There are three degrees of freedom,

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

> 2016/07/22 0:33、Chris Lattner via swift-evolution > のメール： > > Hello Swift community, > > The third review of "SE-0117: Allow distinguishing between public access and > public overridability" begins now and runs through July 25. The proposal is > available here:

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

> On Jul 25, 2016, at 6:38 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Jul 21, 2016, at 8:33 AM, Chris Lattner via swift-evolution >> wrote: >> >> * What is your evaluation of the proposal? > > Of the designs

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

> * What is your evaluation of the proposal? +1 In its third revision I like this proposal more. I think “open” is a good keyword for both members and classes. I’m in favor of the first design for open classes. That said, I also acknowledge that subclassing without overriding anything

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

Thank you very much for clarifying these! My position is now of course back in favor of the proposal. +1 (Sorry for being a stickler; I know what deadlines are like. I hope the team gets a bit of time to rest.) <3, -- Károly @lorentey > On 2016-07-22, at 18:36, John McCall

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

> On Jul 22, 2016, at 9:09 AM, Károly Lőrentey via swift-evolution > wrote: > > On 2016-07-21 15:33:37 +, Chris Lattner via swift-evolution said: >> * What is your evaluation of the proposal? > > I gave enthusiastic thumbs up to the previous two proposals.

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

On 2016-07-21 15:33:37 +, Chris Lattner via swift-evolution said: * What is your evaluation of the proposal? I gave enthusiastic thumbs up to the previous two proposals. I agree wholeheartedly with the underlying goal, and I love the new Motivation section. I'm OK with the idea of

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

> Am 22.07.2016 um 00:29 schrieb Garth Snyder via swift-evolution > : > > In the original proposal (and the ensuing discussion), there was tacit > agreement that subclassability/overridability and access levels should be > orthogonal. However, given the direction

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md - What is your evaluation of the proposal? +1 to the second proposal, if we were to drop the concept of a final class. I feel like by blocking subclasses in preference to

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

+1 [ Long, sorry… ] This version is a big step forward! Thanks for the continued work and comments... I want to propose a small reframing that I think would help to clarify some of the remaining issues. It’s not really a “counterproposal” because I don’t think it actually changes all that

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

> On Jul 21, 2016, at 2:29 PM, Karl via swift-evolution > wrote: > >> On 21 Jul 2016, at 20:49, Chris Lattner > > wrote: >> >> On Jul 21, 2016, at 8:56 AM, Karl > >

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

> • What is your evaluation of the proposal? Breaking it down in parts: +1 to the basic principle of making the external subclassing a conscious, explicit API design decision. +1 to providing a design state for subclassability that leaves the most room for non-breaking future changes. Those

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

> * What is your evaluation of the proposal? +1 as before but for the first implementation. I want to like implementation 2 but I really don’t see the need for it because extensions. The only reason for 2 is if the core team thinks that we will never get stored properties can be added

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

> On 21 Jul 2016, at 20:49, Chris Lattner wrote: > > On Jul 21, 2016, at 8:56 AM, Karl wrote: >> >> Just posted in the Review #2 thread. I read the updated proposal, and I have >> another idea besides making “final” default: > > Hi Karl, > > Please

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

On 21 July 2016 at 12:33, Chris Lattner via swift-evolution wrote: > Hello Swift community, > > The third review of "SE-0117: Allow distinguishing between public access and > public overridability" begins now and runs through July 25. The proposal is > available here:

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

On Jul 21, 2016, at 8:56 AM, Karl wrote: > > Just posted in the Review #2 thread. I read the updated proposal, and I have > another idea besides making “final” default: Hi Karl, Please respond to proposal on this thread with your evaluation of it. This isn’t the right

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

> > *What is your evaluation of the proposal?* Strong +1 to either design, and neutral between them. In the prior review I advocated that `open` should *only* apply to classes, not members. This new proposal turns that on its head and is *vastly superior*. Tagging open members with *just* the

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

On 21.07.2016 18:33, Chris Lattner via swift-evolution wrote: Hello Swift community, The third review of "SE-0117: Allow distinguishing between public access and public overridability" begins now and runs through July 25. The proposal is available here:

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

On Thu, Jul 21, 2016 at 8:33 AM Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > Hello Swift community, > > The third review of "SE-0117: Allow distinguishing between public access > and public overridability" begins now and runs through July 25. The > proposal is available

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

On Thu, Jul 21, 2016 at 10:33 AM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > Hello Swift community, > > The third review of "SE-0117: Allow distinguishing between public access > and public overridability" begins now and runs through July 25. The > proposal is

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

* What is your evaluation of the proposal? +1 for the first design listed. Simplicity is nice but the ability to vend non-final classes that cannot be publicly subclassed is worth the complexity. * Is the problem being addressed significant enough to warrant a change to Swift? Yes.

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

> On 21 Jul 2016, at 17:33, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > The third review of "SE-0117: Allow distinguishing between public access and > public overridability" begins now and runs through July 25. The proposal is >

[swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

Hello Swift community, The third review of "SE-0117: Allow distinguishing between public access and public overridability" begins now and runs through July 25. The proposal is available here: