Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 15, 2017, at 10:57 PM, Rien wrote: > > > >> On 16 Feb 2017, at 03:45, David Smith wrote: >> >>> >>> On Feb 15, 2017, at 8:35 AM, Rien via swift-evolution >>> wrote: >>> On 15 Feb 2017, at 17:02,

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 16, 2017, at 8:21 AM, James Froggatt via swift-evolution > wrote: > > >> On 16 Feb 2017, at 02:13, Jordan Rose wrote: >> >> >>> On Feb 13, 2017, at 09:28, James Froggatt via swift-evolution >>> wrote:

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On 16 Feb 2017, at 02:13, Jordan Rose wrote: > > >> On Feb 13, 2017, at 09:28, James Froggatt via swift-evolution >> wrote: >> >> Having loosely followed this discussion, the way I'm thinking of ‘closed’ is >> as a modifier which would

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On 16 Feb 2017, at 03:45, David Smith wrote: > >> >> On Feb 15, 2017, at 8:35 AM, Rien via swift-evolution >> wrote: >> >>> >>> On 15 Feb 2017, at 17:02, Matthew Johnson wrote: >>> On Feb 15, 2017, at

Re: [swift-evolution] [Pitch] consistent public access modifiers (value subtyping digression)

Sent from my iPad > On Feb 15, 2017, at 8:17 PM, Jordan Rose wrote: > > >>> On Feb 13, 2017, at 09:33, Matthew Johnson via swift-evolution >>> wrote: >>> >>> >>> On Feb 13, 2017, at 11:28 AM, James Froggatt via swift-evolution >>>

Re: [swift-evolution] [Pitch] consistent public access modifiers (value subtyping digression)

Sent from my iPad > On Feb 15, 2017, at 8:17 PM, Jordan Rose wrote: > > >>> On Feb 13, 2017, at 09:33, Matthew Johnson via swift-evolution >>> wrote: >>> >>> >>> On Feb 13, 2017, at 11:28 AM, James Froggatt via swift-evolution >>>

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 15, 2017, at 8:35 AM, Rien via swift-evolution > wrote: > >> >> On 15 Feb 2017, at 17:02, Matthew Johnson wrote: >> >>> >>> On Feb 15, 2017, at 9:59 AM, Rien wrote: >>> On 15 Feb 2017, at 16:45,

Re: [swift-evolution] [Pitch] consistent public access modifiers - protocols

> On Feb 10, 2017, at 12:23, Matthew Johnson wrote: > > >> On Feb 10, 2017, at 12:52 PM, Jordan Rose > > wrote: >> >> Hi, Matthew. Thank you for bringing up these issues. I'm going to break my >> feedback up into

Re: [swift-evolution] [Pitch] consistent public access modifiers (value subtyping digression)

> On Feb 13, 2017, at 09:33, Matthew Johnson via swift-evolution > wrote: > >> >> On Feb 13, 2017, at 11:28 AM, James Froggatt via swift-evolution >> wrote: >> >> Having loosely followed this discussion, the way I'm thinking of ‘closed’

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 13, 2017, at 09:28, James Froggatt via swift-evolution > wrote: > > Having loosely followed this discussion, the way I'm thinking of ‘closed’ is > as a modifier which would let you switch over something from outside the > module in which it is declared. >

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 14, 2017, at 18:16, Xiaodi Wu via swift-evolution > wrote: > > So, perhaps I'm being simplistic here, but-- > > At the end of the day, aren't we simply trying to enable a resiliency > feature? Could it not be said that an enum where future added cases

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 12, 2017, at 21:52, Slava Pestov via swift-evolution > wrote: > > Also, note that there will be at least one other similar annotation, but for > structs — the evolution document calls it @fixedContents. We want a way to > declare that the set of stored

Re: [swift-evolution] [Pitch] consistent public access modifiers

> The Library Evolution document isn’t gospel; it’s more like a collection of > musings and aspirations, so I don’t think we should be bound by the syntax it > uses. Agreed on this very local point. :-) There are some deliberately ugly names in there so that we don't end up using that syntax.

Re: [swift-evolution] [Pitch] consistent public access modifiers

Types have a ton of different implicit/explicit “API”, and access control modifiers often implicitly define that API: - API for everyone to use when dealing with your concrete type (“public”) - API for module code when you have related, coupled types that need a higher degree of knowledge

Re: [swift-evolution] [Pitch] consistent public access modifiers

Not a huge response, but how about locked? --  Adrian Zubarev Sent with Airmail Am 15. Februar 2017 um 20:31:30, Matthew Johnson via swift-evolution (swift-evolution@swift.org) schrieb: > On Feb 14, 2017, at 3:43 AM, Brent Royal-Gordon > wrote: > >> On Feb 13,

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 14, 2017, at 3:43 AM, Brent Royal-Gordon > wrote: > >> On Feb 13, 2017, at 7:45 AM, Matthew Johnson wrote: >> >> If you look closely, when most people say “closed enum” they mean a fixed, >> complete set of cases that are all public.

Re: [swift-evolution] [Pitch] consistent public access modifiers

> > On 15 Feb 2017, at 19:27, Adrian Zubarev > wrote: > > Inline: > > -- > Adrian Zubarev > Sent with Airmail > > Am 15. Februar 2017 um 19:11:12, Rien (r...@balancingrock.nl) schrieb: > >> >> > On 15 Feb 2017, at 18:09, Adrian Zubarev

Re: [swift-evolution] [Pitch] consistent public access modifiers

If you happen not to bump into these issues yet, then simply call yourself lucky. ;) --  Adrian Zubarev Sent with Airmail Am 15. Februar 2017 um 19:27:06, Adrian Zubarev (adrian.zuba...@devandartist.com) schrieb: Inline: --  Adrian Zubarev Sent with Airmail Am 15. Februar 2017 um 19:11:12,

Re: [swift-evolution] [Pitch] consistent public access modifiers

Inline: --  Adrian Zubarev Sent with Airmail Am 15. Februar 2017 um 19:11:12, Rien (r...@balancingrock.nl) schrieb: > On 15 Feb 2017, at 18:09, Adrian Zubarev > wrote:  >  > As I already said:  >  > • To make that feature happen, we need the protocol to be

Re: [swift-evolution] [Pitch] consistent public access modifiers

I’ll try again to make it a little bit more simpler. Assume we want to implement my feature to support document["string_literal", stringInstance, integerInstance, 42] where the first parameter type is always a String but the types follow afterward are either a String or an Int (literals should

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On 15 Feb 2017, at 18:09, Adrian Zubarev > wrote: > > As I already said: > > • To make that feature happen, we need the protocol to be public > (regardless if you can conform to it or not). > • Today you can conform to every protocol because in

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On 15 Feb 2017, at 17:45, Matthew Johnson wrote: > > >> On Feb 15, 2017, at 10:35 AM, Rien wrote: >> >>> >>> On 15 Feb 2017, at 17:02, Matthew Johnson wrote: >>> On Feb 15, 2017, at 9:59 AM, Rien

Re: [swift-evolution] [Pitch] consistent public access modifiers

To summarize everything, I think whenever we get submodules in Swift having a consistent public vs. open behavior would have a great impact when some of us will work on huge (team) projects. I do not actively support the idea of @closed. I see its benefits, but first I need to get my head

Re: [swift-evolution] [Pitch] consistent public access modifiers

As I already said: To make that feature happen, we need the protocol to be public (regardless if you can conform to it or not). Today you can conform to every protocol because in reality they are open today. If we remove the property requirement from the protocol the client can conform it to

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On 15 Feb 2017, at 17:22, Adrian Zubarev via swift-evolution > wrote: > > A short example where I personally wanted a public-but-not-open protocol: > > public protocol SubscriptParameterType { > > // This property was needed to prevent the client from

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 15, 2017, at 10:35 AM, Rien wrote: > >> >> On 15 Feb 2017, at 17:02, Matthew Johnson wrote: >> >>> >>> On Feb 15, 2017, at 9:59 AM, Rien wrote: >>> On 15 Feb 2017, at 16:45, Matthew Johnson

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On 15 Feb 2017, at 17:02, Matthew Johnson wrote: > >> >> On Feb 15, 2017, at 9:59 AM, Rien wrote: >> >>> >>> On 15 Feb 2017, at 16:45, Matthew Johnson wrote: >>> On Feb 15, 2017, at 9:35 AM, Rien

Re: [swift-evolution] [Pitch] consistent public access modifiers

A short example where I personally wanted a public-but-not-open protocol: public protocol SubscriptParameterType { // This property was needed to prevent the client from breaking // the library by conforming to the protocol, but I'd like to // keep it invisible for the client,

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 15, 2017, at 9:59 AM, Rien wrote: > >> >> On 15 Feb 2017, at 16:45, Matthew Johnson wrote: >> >>> >>> On Feb 15, 2017, at 9:35 AM, Rien wrote: >>> >>> On 15 Feb 2017, at 16:11, Matthew Johnson via

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On 15 Feb 2017, at 16:45, Matthew Johnson wrote: > >> >> On Feb 15, 2017, at 9:35 AM, Rien wrote: >> >> >>> On 15 Feb 2017, at 16:11, Matthew Johnson via swift-evolution >>> wrote: >>> >>> On Feb 15, 2017,

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 15, 2017, at 9:35 AM, Rien wrote: > > >> On 15 Feb 2017, at 16:11, Matthew Johnson via swift-evolution >> wrote: >> >> >>> On Feb 15, 2017, at 5:59 AM, Jeremy Pereira via swift-evolution >>> wrote: >>>

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On 15 Feb 2017, at 16:11, Matthew Johnson via swift-evolution > wrote: > > >> On Feb 15, 2017, at 5:59 AM, Jeremy Pereira via swift-evolution >> wrote: >> >> >>> On 15 Feb 2017, at 11:11, Brent Royal-Gordon via swift-evolution >>>

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 15, 2017, at 5:59 AM, Jeremy Pereira via swift-evolution > wrote: > > >> On 15 Feb 2017, at 11:11, Brent Royal-Gordon via swift-evolution >> wrote: >> >> >> Our philosophy in general, however, is to default to the behavior

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 15, 2017, at 5:52 AM, Jeremy Pereira > wrote: > > >> On 15 Feb 2017, at 02:16, Xiaodi Wu via swift-evolution >> wrote: >> >> So, perhaps I'm being simplistic here, but-- >> >> At the end of the day, aren't we simply

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 15, 2017, at 5:11 AM, Brent Royal-Gordon > wrote: > >> On Feb 14, 2017, at 6:16 PM, Xiaodi Wu wrote: >> >> So, perhaps I'm being simplistic here, but-- >> >> At the end of the day, aren't we simply trying to enable a resiliency >>

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On 15 Feb 2017, at 11:11, Brent Royal-Gordon via swift-evolution > wrote: > > > Our philosophy in general, however, is to default to the behavior which > preserves the most flexibility for the library designer. Actually, I thought the philosophy was to preserver

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On 15 Feb 2017, at 02:16, Xiaodi Wu via swift-evolution > wrote: > > So, perhaps I'm being simplistic here, but-- > > At the end of the day, aren't we simply trying to enable a resiliency > feature? Could it not be said that an enum where future added cases

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 14, 2017, at 6:16 PM, Xiaodi Wu wrote: > > So, perhaps I'm being simplistic here, but-- > > At the end of the day, aren't we simply trying to enable a resiliency > feature? Could it not be said that an enum where future added cases aren't > source-breaking is a

Re: [swift-evolution] [Pitch] consistent public access modifiers

So, perhaps I'm being simplistic here, but-- At the end of the day, aren't we simply trying to enable a resiliency feature? Could it not be said that an enum where future added cases aren't source-breaking is a more resilient enum? Since there is consensus that the status quo is desirable for a

Re: [swift-evolution] [Pitch] consistent public access modifiers - enums

Hi, Matthew. Sorry for the delay in sending my second message. As stated before: > I'm going to break my feedback up into separate messages, because I think > really the enum and protocol cases are unrelated. Open classes refer to > classes that can be subclassed from clients of the current

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 14, 2017, at 3:43 AM, Brent Royal-Gordon > wrote: > >> On Feb 13, 2017, at 7:45 AM, Matthew Johnson wrote: >> >> If you look closely, when most people say “closed enum” they mean a fixed, >> complete set of cases that are all public.

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 13, 2017, at 7:45 AM, Matthew Johnson wrote: > > If you look closely, when most people say “closed enum” they mean a fixed, > complete set of cases that are all public. But when people say “closed > protocol” they don’t actually mean a fixed, complete set of

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 13, 2017, at 8:14 AM, Adrian Zubarev > wrote: > > Is that assumption correct? > > // Module A > public protocol SQLiteValue { > init(statement: SQLiteStatement, columnAt index: Int) throws > func bind(to statement: SQLiteStatement, at index:

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 13, 2017, at 11:28 AM, James Froggatt via swift-evolution > wrote: > > Having loosely followed this discussion, the way I'm thinking of ‘closed’ is > as a modifier which would let you switch over something from outside the > module in which it is declared.

Re: [swift-evolution] [Pitch] consistent public access modifiers

Having loosely followed this discussion, the way I'm thinking of ‘closed’ is as a modifier which would let you switch over something from outside the module in which it is declared. From outside the declaring module: • A closed enum's cases can be exhaustively switched. • A closed protocol's

Re: [swift-evolution] [Pitch] consistent public access modifiers

Okay thanks, that makes now sense to me. So even if we refine public protocols from module A with a custom protocol in module B, there is no way we can conform any other type from module B to it, but we could conform existing types of module A to our refined protocols. That’s fine by me,

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 13, 2017, at 10:14 AM, Adrian Zubarev via swift-evolution > wrote: > > Is that assumption correct? > > // Module A > public protocol SQLiteValue { > init(statement: SQLiteStatement, columnAt index: Int) throws > func bind(to statement:

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 13, 2017, at 10:19 AM, Karl Wagner wrote: > >> >>> >>> As I mentioned earlier, I don't think `closed` is a good keyword standing >>> alone. And I also think that, given that we have `open`, `closed` also >>> won't pair well with `public`—they sound like antonyms

Re: [swift-evolution] [Pitch] consistent public access modifiers

> >> >> As I mentioned earlier, I don't think `closed` is a good keyword standing >> alone. And I also think that, given that we have `open`, `closed` also won't >> pair well with `public`—they sound like antonyms when they aren’t. > > The semantics I am proposing do have an inverse

Re: [swift-evolution] [Pitch] consistent public access modifiers

Is that assumption correct? // Module A public protocol SQLiteValue { init(statement: SQLiteStatement, columnAt index: Int) throws func bind(to statement: SQLiteStatement, at index: Int) throws } // Module B protocol SQLiteLoggable : SQLiteValue { var logDescription: String { get } }

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 13, 2017, at 8:24 AM, Brent Royal-Gordon > wrote: > > Sorry, I meant to jump in a lot earlier than this, but lost track of this > thread on my mental to-do list. I've read most of the thread, but I really > can't keep all the replies in my head at once, so I

Re: [swift-evolution] [Pitch] consistent public access modifiers

Sorry, I meant to jump in a lot earlier than this, but lost track of this thread on my mental to-do list. I've read most of the thread, but I really can't keep all the replies in my head at once, so I apologize if some of this is duplicative. I agree with Jordan Rose that "closed enums" and

Re: [swift-evolution] [Pitch] consistent public access modifiers

Also, note that there will be at least one other similar annotation, but for structs — the evolution document calls it @fixedContents. We want a way to declare that the set of stored properties in a struct will never change, allowing clients to make assumptions about its layout. Unlike @closed

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 12, 2017, at 10:39 AM, Nevin Brackett-Rozinsky via swift-evolution > wrote: > > Alternative: leave “public enum” as it is now, and spell the resilient > version “@resilient enum” The problem with this approach is that the “default” is the stricter contract

Re: [swift-evolution] [Pitch] consistent public access modifiers

Alternative: leave “public enum” as it is now, and spell the resilient version “@resilient enum” Nevin On Sunday, February 12, 2017, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > > On Feb 12, 2017, at 10:24 AM, David Hart

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 12, 2017, at 10:24 AM, David Hart wrote: > > > On 12 Feb 2017, at 16:38, Matthew Johnson > wrote: > >> >>> On Feb 12, 2017, at 12:50 AM, David Hart >> > wrote:

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On 12 Feb 2017, at 16:38, Matthew Johnson wrote: > > >> On Feb 12, 2017, at 12:50 AM, David Hart wrote: >> >> Hi Matthew, >> >> I've read your proposal ideas and most of the discussions on the thread, and >> I'd like to provide some personal

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 12, 2017, at 12:50 AM, David Hart wrote: > > Hi Matthew, > > I've read your proposal ideas and most of the discussions on the thread, and > I'd like to provide some personal feedback. > > Swift already has a complicated "access modifier" story so I think we really

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 11, 2017, at 4:41 PM, Karl Wagner wrote: > > >> On 11 Feb 2017, at 20:50, Matthew Johnson via swift-evolution >> > wrote: >> >>> >>> On Feb 11, 2017, at 12:40 PM, Xiaodi Wu >>

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 11, 2017, at 2:41 PM, Karl Wagner via swift-evolution > wrote: > For example, the compiler squashes the layout of an enum in to the smallest > type which can represent all of its cases - so if you only have 2 cases, your > enum will be an Int1 (possibly

Re: [swift-evolution] [Pitch] consistent public access modifiers

Hi Brent, I understand that SubC.cc as C does not work, that’s the case in my bikeshedding example I noticed that because the enum case is always known at compile time, there will be an error with informs you to downgrade SubC to one of its super-types case. Plus I forget about the

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 11, 2017, at 2:25 AM, Adrian Zubarev via swift-evolution > wrote: > > // Allowed because `C` is open, and open allows sub-typing, conforming > // and overriding to the client > enum SubC : C { > case cc > } There's a subtle mistake here. For a sum

Re: [swift-evolution] [Pitch] consistent public access modifiers

Hi Matthew, I've read your proposal ideas and most of the discussions on the thread, and I'd like to provide some personal feedback. Swift already has a complicated "access modifier" story so I think we really want a good reason to introduce a new one. And the problem I see is that `closed`

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On 11 Feb 2017, at 20:50, Matthew Johnson via swift-evolution > wrote: > >> >> On Feb 11, 2017, at 12:40 PM, Xiaodi Wu > > wrote: >> >> On Sat, Feb 11, 2017 at 6:41 AM, Matthew Johnson >

Re: [swift-evolution] [Pitch] consistent public access modifiers

On Sat, Feb 11, 2017 at 1:50 PM, Matthew Johnson wrote: > > On Feb 11, 2017, at 12:40 PM, Xiaodi Wu wrote: > > On Sat, Feb 11, 2017 at 6:41 AM, Matthew Johnson > wrote: > >> >> >> Sent from my iPad >> >> On Feb 10, 2017, at

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 11, 2017, at 12:40 PM, Xiaodi Wu wrote: > > On Sat, Feb 11, 2017 at 6:41 AM, Matthew Johnson > wrote: > > > Sent from my iPad > > On Feb 10, 2017, at 9:48 PM, Xiaodi Wu

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 11, 2017, at 7:56 AM, Karl Wagner wrote: > > >> On 11 Feb 2017, at 14:37, Karl Wagner > > wrote: >> >> >>> On 9 Feb 2017, at 00:05, Matthew Johnson via swift-evolution >>>

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 11, 2017, at 7:37 AM, Karl Wagner wrote: > > >> On 9 Feb 2017, at 00:05, Matthew Johnson via swift-evolution >> > wrote: >> >> I’ve been thinking a lot about our public access modifier story lately in

Re: [swift-evolution] [Pitch] consistent public access modifiers

On Sat, Feb 11, 2017 at 12:53 PM, Matthew Johnson wrote: > > > Sent from my iPad > > On Feb 11, 2017, at 12:44 PM, Xiaodi Wu wrote: > > On Sat, Feb 11, 2017 at 12:42 PM, Matthew Johnson via swift-evolution < > swift-evolution@swift.org> wrote: > >>

Re: [swift-evolution] [Pitch] consistent public access modifiers

Sent from my iPad > On Feb 11, 2017, at 12:44 PM, Xiaodi Wu wrote: > >> On Sat, Feb 11, 2017 at 12:42 PM, Matthew Johnson via swift-evolution >> wrote: >> >> >> Sent from my iPad >> >> > On Feb 11, 2017, at 7:22 AM, Rien

Re: [swift-evolution] [Pitch] consistent public access modifiers

I’m definitely looking forward to this, it’s a highly interesting topic to follow. :) Thank you for all your hard work. --  Adrian Zubarev Sent with Airmail Am 11. Februar 2017 um 19:47:36, Matthew Johnson (matt...@anandabits.com) schrieb: Sent from my iPad On Feb 11, 2017, at 12:38 PM,

Re: [swift-evolution] [Pitch] consistent public access modifiers

Sent from my iPad > On Feb 11, 2017, at 12:38 PM, Adrian Zubarev via swift-evolution > wrote: > > That makes actually sense to me if we think of it that we never will get any > sub-typing for enums. I’m still undecided on that sub-typing topic about > value

Re: [swift-evolution] [Pitch] consistent public access modifiers

On Sat, Feb 11, 2017 at 12:42 PM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > > > Sent from my iPad > > > On Feb 11, 2017, at 7:22 AM, Rien wrote: > > > > I admit that I have not followed all of this discussion, but as far as I > see, we could

Re: [swift-evolution] [Pitch] consistent public access modifiers

Sent from my iPad > On Feb 11, 2017, at 7:22 AM, Rien wrote: > > I admit that I have not followed all of this discussion, but as far as I see, > we could equally well do this by calling “not-open” enum’s “final”. > It seems like a better fit to me. That is actually

Re: [swift-evolution] [Pitch] consistent public access modifiers

On Sat, Feb 11, 2017 at 6:41 AM, Matthew Johnson wrote: > > > Sent from my iPad > > On Feb 10, 2017, at 9:48 PM, Xiaodi Wu wrote: > > On Wed, Feb 8, 2017 at 5:05 PM, Matthew Johnson via swift-evolution < > swift-evolution@swift.org> wrote: > >> I’ve

Re: [swift-evolution] [Pitch] consistent public access modifiers

That makes actually sense to me if we think of it that we never will get any sub-typing for enums. I’m still undecided on that sub-typing topic about value types. Just out of curiosity it would be interesting to hear from the core team if this would be a future direction for Swift or not, be it

Re: [swift-evolution] [Pitch] consistent public access modifiers

Sent from my iPad > On Feb 11, 2017, at 12:30 PM, Xiaodi Wu wrote: > > I think Matthew's point (with which I agree) is that, as enums are sum types, > adding or removing cases is akin to subclassing. You can extend a public enum > by adding methods just like you can

Re: [swift-evolution] [Pitch] consistent public access modifiers

I think Matthew's point (with which I agree) is that, as enums are sum types, adding or removing cases is akin to subclassing. You can extend a public enum by adding methods just like you can extend a public class. But just as you cannot subclass a public class, you should not be able to add or

Re: [swift-evolution] [Pitch] consistent public access modifiers

I have to correct myself here and there. … which would be extensible if that feature might be added to swift one day. Again, I see open only as a contract to allow sub-typing, conformances and overriding to the client, where extensibility of a type a story of it’s own. --  Adrian Zubarev Sent

Re: [swift-evolution] [Pitch] consistent public access modifiers

It wasn’t my intention to drive to far way off topic with this. The major point of my last bike shedding was that I have to disagree with you about the potential future open enum vs. public enum and closed enum. public today does not add any guarantee to prevent the client from extending your

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On 11 Feb 2017, at 14:37, Karl Wagner wrote: > > >> On 9 Feb 2017, at 00:05, Matthew Johnson via swift-evolution >> > wrote: >> >> I’ve been thinking a lot about our public access modifier story lately

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On 9 Feb 2017, at 00:05, Matthew Johnson via swift-evolution > wrote: > > I’ve been thinking a lot about our public access modifier story lately in the > context of both protocols and enums. I believe we should move further in the > direction we took when

Re: [swift-evolution] [Pitch] consistent public access modifiers

I admit that I have not followed all of this discussion, but as far as I see, we could equally well do this by calling “not-open” enum’s “final”. It seems like a better fit to me. Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github:

Re: [swift-evolution] [Pitch] consistent public access modifiers

Sent from my iPad > On Feb 11, 2017, at 4:25 AM, Adrian Zubarev via swift-evolution > wrote: > > I’m probably better describing things with some bikeshedding code, but feel > free to criticize it as much as you’d like. > > //===- Module A

Re: [swift-evolution] [Pitch] consistent public access modifiers

Sent from my iPad > On Feb 10, 2017, at 9:48 PM, Xiaodi Wu wrote: > >> On Wed, Feb 8, 2017 at 5:05 PM, Matthew Johnson via swift-evolution >> wrote: >> I’ve been thinking a lot about our public access modifier story lately in >> the context

Re: [swift-evolution] [Pitch] consistent public access modifiers

Sent from my iPad > On Feb 10, 2017, at 9:35 PM, Xiaodi Wu wrote: > >> On Fri, Feb 10, 2017 at 9:15 AM, Matthew Johnson >> wrote: >> >>> On Feb 10, 2017, at 1:06 AM, Xiaodi Wu wrote: >>> On Thu, Feb 9, 2017 at 9:57

Re: [swift-evolution] [Pitch] consistent public access modifiers

I’m probably better describing things with some bikeshedding code, but feel free to criticize it as much as you’d like. //===- Module A -===// @closed public enum A { case a } extension A { case aa // error, because enum is closed } public func foo(a: A)

Re: [swift-evolution] [Pitch] consistent public access modifiers

On Wed, Feb 8, 2017 at 5:05 PM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > I’ve been thinking a lot about our public access modifier story lately in > the context of both protocols and enums. I believe we should move further > in the direction we took when

Re: [swift-evolution] [Pitch] consistent public access modifiers

On Fri, Feb 10, 2017 at 9:15 AM, Matthew Johnson wrote: > > On Feb 10, 2017, at 1:06 AM, Xiaodi Wu wrote: > > On Thu, Feb 9, 2017 at 9:57 AM, Matthew Johnson > wrote: > >> >> On Feb 8, 2017, at 5:48 PM, Xiaodi Wu

Re: [swift-evolution] [Pitch] consistent public access modifiers - protocols

> On Feb 10, 2017, at 12:52 PM, Jordan Rose wrote: > > Hi, Matthew. Thank you for bringing up these issues. I'm going to break my > feedback up into separate messages, because I think really the enum and > protocol cases are unrelated. Open classes refer to classes that

Re: [swift-evolution] [Pitch] consistent public access modifiers - protocols

Hello Jordan, having a clear and constructive opinion like yours is much appreciated in this topic. As a disclaimer, I haven’t followed the original topic about the new open access modifier that much last year. At day one, when Swift 3 was released, I noticed open everywhere in Apples

Re: [swift-evolution] [Pitch] consistent public access modifiers - protocols

Hi, Matthew. Thank you for bringing up these issues. I'm going to break my feedback up into separate messages, because I think really the enum and protocol cases are unrelated. Open classes refer to classes that can be subclassed from clients of the current module, and similarly open protocols

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 10, 2017, at 1:06 AM, Xiaodi Wu wrote: > > On Thu, Feb 9, 2017 at 9:57 AM, Matthew Johnson > wrote: > >> On Feb 8, 2017, at 5:48 PM, Xiaodi Wu > > wrote:

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 9, 2017, at 10:33 AM, Adrian Zubarev > wrote: > > The last explanation is great, now I could follow the idea behind the > proposed closed keyword/access modifier. I do now understand the contract on > enums, but I’m struggling to understand how

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 8, 2017, at 7:02 PM, Adrian Zubarev via swift-evolution > wrote: > > Hurray, I cannot wait to get the consistent behavior of open/public > protocols. I’m not sure I could follow the idea behind the proposed closed > keyboard/access modifier. It almost felt

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 8, 2017, at 5:48 PM, Xiaodi Wu wrote: > > I agree very much with rationalizing access levels, but I'm not sure I like > this proposal for public vs. closed. How would the compiler stop me from > editing my own code if something is closed? The answer must be that

Re: [swift-evolution] [Pitch] consistent public access modifiers

on Wed Feb 08 2017, Xiaodi Wu wrote: > I agree very much with rationalizing access levels, but I'm not sure I like > this proposal for public vs. closed. How would the compiler stop me from > editing my own code if something is closed? The answer must be that it >

Re: [swift-evolution] [Pitch] consistent public access modifiers

Hurray, I cannot wait to get the consistent behavior of open/public protocols. I’m not sure I could follow the idea behind the proposed closed keyboard/access modifier. It almost felt like closed == final public, am I mistaken something here? Furthermore, I really would love if the community

Re: [swift-evolution] [Pitch] consistent public access modifiers

I agree very much with rationalizing access levels, but I'm not sure I like this proposal for public vs. closed. How would the compiler stop me from editing my own code if something is closed? The answer must be that it can't, so I can't see it as a co-equal to open but rather simply a statement

[swift-evolution] [Pitch] consistent public access modifiers

I’ve been thinking a lot about our public access modifier story lately in the context of both protocols and enums. I believe we should move further in the direction we took when introducing the `open` keyword. I have identified what I think is a promising direction and am interested in

  1   2   >