Re: [swift-evolution] Protected Access

While that’s true, it’s pretty clearly a hack. Having this built into the language would not only be a lot more elegant, but could also prevent override-only methods from showing up in Xcode’s autocomplete. Charles > On Oct 7, 2016, at 6:36 PM, Callionica (Swift) via swift-evolution >

Re: [swift-evolution] private & fileprivate

On Fri, Oct 7, 2016 at 8:49 PM, Braeden Profile via swift-evolution < swift-evolution@swift.org> wrote: > > > > On Oct 7, 2016, at 5:46 PM, Trans via swift-evolution < > swift-evolution@swift.org> wrote: > > > > Private access that limits exposure to extensions and subclasses is > > the bane of

Re: [swift-evolution] Taking advantage of our character space

On Fri, Oct 7, 2016 at 6:22 PM, Jonathan Hull via swift-evolution < swift-evolution@swift.org> wrote: > This is a quick one. It would be nice to take advantage of all the > wonderful characters that swift can use. Not only unicode, but some of the > less-used ASCII as well. > > In particular, I

Re: [swift-evolution] Protected Access

Jon--earlier in the week, there was another thread which once against raised the idea of internal or private protocol conformances; would that be another way of addressing your use case here? On Fri, Oct 7, 2016 at 6:36 PM, Callionica (Swift) via swift-evolution < swift-evolution@swift.org>

Re: [swift-evolution] private & fileprivate

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

Re: [swift-evolution] Protected Access

For overridable, but not callable, you can use the technique outlined at http://www.callionica.com/developer/#swift-protected (give your method a parameter of a type that only the base class can create) On Friday, October 7, 2016, Jonathan Hull via swift-evolution < swift-evolution@swift.org>

[swift-evolution] Taking advantage of our character space

This is a quick one. It would be nice to take advantage of all the wonderful characters that swift can use. Not only unicode, but some of the less-used ASCII as well. In particular, I would like to see: 1) Allow the ‘π’ character as a FloatingPoint literal. We can use CGFloat.pi and

Re: [swift-evolution] private & fileprivate

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

Re: [swift-evolution] private & fileprivate

While I agree that private/fileprivate didn't change much… I have to say that I wish we had simply kept private as is and ended up with private, internal, public, and open. It is more tricky to explain than it is worth. TJ On Fri, Oct 7, 2016 at 6:56 PM, Jordan Rose via swift-evolution <

Re: [swift-evolution] private & fileprivate

> On Oct 7, 2016, at 15:15, William Sumner via swift-evolution > wrote: > > >> On Oct 7, 2016, at 3:05 PM, Zach Waldowski via swift-evolution >> > wrote: >> >> I third this sentiment. fileprivate is a

Re: [swift-evolution] Propagating Optionals

On Sun, Sep 25, 2016 at 4:19 PM, Trans via swift-evolution < swift-evolution@swift.org> wrote: > As I've been learning Swift recently, one aspect of the language > jumped out at me with a "code smell". Namely, the way Optionals are > handled. For starters, just consider how long this chapter is:

Re: [swift-evolution] private & fileprivate

> On Oct 7, 2016, at 3:05 PM, Zach Waldowski via swift-evolution > wrote: > > I third this sentiment. fileprivate is a nice idea and very clearly has its > uses (which is why the proposal got traction in the first place), but when > combined with the other access

Re: [swift-evolution] Fwd: Propagating Optionals

> On Oct 7, 2016, at 2:56 PM, Trans via swift-evolution > wrote: > > Just discovered that none of my replies made it to the mailing list. > Doesn't it bug others that the default reply is to the author and not > the list? > > > -- Forwarded message

Re: [swift-evolution] Protected Access

I agree with and also feel access modifiers / controls are missing and the ones we have may not be the best if you factor in these additional needs. I also agree that I would prefer the discussion be more focused on this type of thing. Thanks for capturing some of the things you have seen (I have

[swift-evolution] Protected Access

The discussion of private/fileprivate reminded me of other access modifier issues that have been bugging me. I agree that the old system is better, but I am ambivalent about changing it back… What I pretty much constantly want is an access modifier which lets me access something from an

[swift-evolution] Fwd: Propagating Optionals

On Sun, Sep 25, 2016 at 9:22 PM, Brent Royal-Gordon wrote: > > Not true; it's an attempt to access the `numberOfRooms` property on > `Optional`. That property doesn't exist, but it could be added > using an extension. > > (And `Optional` does have several members—most

[swift-evolution] Fwd: Propagating Optionals

On Mon, Sep 26, 2016 at 4:08 AM, Haravikk wrote: > >> On 25 Sep 2016, at 21:19, Trans via swift-evolution >> wrote: >> >> "john.residence.numberOfRooms" could just behave one way or the other > > While I understand where you're coming

[swift-evolution] Fwd: Propagating Optionals

Just discovered that none of my replies made it to the mailing list. Doesn't it bug others that the default reply is to the author and not the list? -- Forwarded message -- From: Trans Date: Sun, Sep 25, 2016 at 9:36 PM Subject: Re: [swift-evolution]

Re: [swift-evolution] private & fileprivate

I actually feel exactly the opposite of this—personally I thought `private` was fine the way it was when it meant `fileprivate` and I had no real need for `private` as it exists in Swift 3. `fileprivate` is useful because it lets me organize my code in such a way that I divide large types (for

Re: [swift-evolution] private & fileprivate

I do see dislike of the name, I get that, I among others pushed for alternate naming (kinda preferred keeping "private" at file scope). What isn't clear to me is - at least for some - folks asking to remove it what they actually mean... or what confusion actually exists other then being something

Re: [swift-evolution] [Pitch] Making some RawRepresentable things bridge to ObjC as their raw value

> On Oct 7, 2016, at 2:11 PM, Dave Abrahams via swift-evolution > wrote: > > > on Mon Oct 03 2016, Joe Groff > wrote: > >>> On Sep 30, 2016, at 10:48 PM, Russ Bishop wrote: >>> >>>

Re: [swift-evolution] [Pitch] Making some RawRepresentable things bridge to ObjC as their raw value

on Mon Oct 03 2016, Joe Groff wrote: >> On Sep 30, 2016, at 10:48 PM, Russ Bishop wrote: >> >> >>> On Sep 29, 2016, at 11:45 AM, Douglas Gregor via swift-evolution >>> > wrote: > >>> >>> >>> Personally, I

Re: [swift-evolution] private & fileprivate

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

Re: [swift-evolution] private & fileprivate

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

Re: [swift-evolution] private & fileprivate

I third this sentiment. fileprivate is a nice idea and very clearly has its uses (which is why the proposal got traction in the first place), but when combined with the other access levels, the language feature as a whole feels arbitrary. In practical use, files that I felt were nicely

Re: [swift-evolution] [Pitch] Making some RawRepresentable things bridge to ObjC as their raw value

> On Oct 3, 2016, at 9:23 AM, Joe Groff wrote: > >> >> On Sep 30, 2016, at 10:48 PM, Russ Bishop wrote: >> >> >>> On Sep 29, 2016, at 11:45 AM, Douglas Gregor via swift-evolution >>> wrote: >>> >>> >>> Personally, I

Re: [swift-evolution] private & fileprivate

> On Oct 7, 2016, at 9:13 AM, David Hart via swift-evolution > wrote: > > I started the topic, but I also believe like you that the fileprivate vs > private(file) discussion has already been thoroughly discussed and nothing > new has been brought up. That’s not

Re: [swift-evolution] private & fileprivate

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

Re: [swift-evolution] [Pitch] open/public protocols

> On Oct 7, 2016, at 10:44 AM, Goffredo Marocchi wrote: > I would say we should, I think we moved a bit hastily and the strict push for > non subclassable by default and the sealed by default discussion may still > yield nasty side effects that are exponentially costlier as

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

What happened to that talk? Were any decisions made internally? Any news? --  Adrian Zubarev Sent with Airmail Am 21. August 2016 um 17:36:53, Michie via swift-evolution (swift-evolution@swift.org) schrieb: Incase, the Swift team decided to use a forum. I would like to suggest Discourse

Re: [swift-evolution] [Pitch] open/public protocols

> On Oct 7, 2016, at 11:05 AM, Goffredo Marocchi via swift-evolution > wrote: > > True too, but dust settling will mean that for each speck the justification > burden will rise quite massively. Not fixing this for Swift 4 phase 1 may > mean a breaking change very

Re: [swift-evolution] [Pich] allow embed type declaration in protocol & allow throw in property getter/setter

+1 for nested everything (yes even extensions for local reasons where sometime you don’t want to write extension Outer.Middle.Inner) and maybe another shorthand form for nesting types. We already have this extension Outer.Inner { … }. So why not allow struct/enum/class/protocol Outer.NewName {

Re: [swift-evolution] [Pitch] open/public protocols

True too, but dust settling will mean that for each speck the justification burden will rise quite massively. Not fixing this for Swift 4 phase 1 may mean a breaking change very very hard to justify for Swift 4 phase 2 which is for additive changes IIRC and even harder for Swift 5 and harder

Re: [swift-evolution] [Pich] allow embed type declaration in protocol & allow throw in property getter/setter

+1 nested types in protocols And nested protocols in types. -1 on throwing properties. > On Oct 7, 2016, at 10:30 AM, Cao Jiannan via swift-evolution > wrote: > > 1. allow embed type declaration in protocol > e.g.: > > protocol URLProvider { >fun url() throws

Re: [swift-evolution] [Pitch] open/public protocols

I don’t disagree that there may have been some hasty movement on this originally, but I don’t think the solution is to move hastily again and second-guess everything before the dust has even had time to settle. l8r Sean > On Oct 7, 2016, at 12:44 PM, Goffredo Marocchi via swift-evolution >

Re: [swift-evolution] [Pitch] open/public protocols

I would say we should, I think we moved a bit hastily and the strict push for non subclassable by default and the sealed by default discussion may still yield nasty side effects that are exponentially costlier as we move to Swift 4+ Sent from my iPhone > On 7 Oct 2016, at 17:40, Adrian Zubarev

Re: [swift-evolution] [Pitch] open/public protocols

Shall we revive this discussion? --  Adrian Zubarev Sent with Airmail Am 25. August 2016 um 19:29:13, John McCall (rjmcc...@apple.com) schrieb: On Aug 25, 2016, at 2:29 AM, Karl via swift-evolution wrote: This is not a new inconsistency. We’ve known about this

Re: [swift-evolution] private & fileprivate

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

Re: [swift-evolution] private & fileprivate

I’m +1 on the following: current new private private fileprivate private(file) internal private(module) public public open open The only thing that keeps bothering me is private(set) and how it will harmonize with this proposed scheme. Regards, Adrian Kashivskyy > Wiadomość napisana przez

Re: [swift-evolution] private & fileprivate

> On Oct 6, 2016, at 11:39 PM, David Hart via swift-evolution > wrote: > > Hello community, > > From all the proposals which has gone into Swift 3, [SE-0025] Scoped Access > Level is the only one I’m having second thoughts about. Before launching a > discussion

Re: [swift-evolution] private & fileprivate

I'd prefer to use public(file), etc over private. You are determining which code has access over which code doesn't. I don't think its that confusing to say the default is just public(module) Sent with my Thumbs > On Oct 7, 2016, at 9:21 AM, Xiaodi Wu via swift-evolution >

[swift-evolution] [Pich] allow embed type declaration in protocol & allow throw in property getter/setter

1. allow embed type declaration in protocol e.g.: protocol URLProvider { fun url() throws -> URL } extension URLProvider { enum Error: Swift.Error { invalidBaseURL invalidPath invalidQuery invalidFragment } } func parseURL() throws -> URL {

Re: [swift-evolution] private & fileprivate

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

Re: [swift-evolution] private & fileprivate

Even if these access modifier names seem to make sense, I don’t really see the need of the reconsideration here. private(scope) == private private(file) == fileprivate private(module) == internal Lhs does add more noise, and if I had to tell, fileprivate actually reads well and better than

Re: [swift-evolution] private & fileprivate

+1 I would also rather have: private(scope) private(file) private(module) etc… — A > On Oct 7, 2016, at 4:24 AM, Haravikk via swift-evolution > wrote: > > >> On 7 Oct 2016, at 07:39, David Hart via swift-evolution >>

Re: [swift-evolution] private & fileprivate

I actually prefer "fileprivate" to the alternatives, but imo using the word "private" is a bad choice for this, since it's basically a relative term. If we're going with parens "visibility(file)" makes more sense to me. On Fri, Oct 7, 2016 at 5:00 AM, Georgios Moschovitis via swift-evolution <

Re: [swift-evolution] private & fileprivate

> On 7 Oct 2016, at 12:11, Jay Abbott wrote: > > I agree that the keywords could be improved, but private(file) access should > not be what 'private' means by itself. If I put just 'private' in front of > something I really mean it should be private to this scope, the most

Re: [swift-evolution] private & fileprivate

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

Re: [swift-evolution] private & fileprivate

I agree that the keywords could be improved, but private(file) access should not be what 'private' means by itself. If I put just 'private' in front of something I really mean it should be private to this scope, the most private. I also think the more common use-case would be private(scope) over

Re: [swift-evolution] private & fileprivate

On 07.10.2016 11:24, Haravikk via swift-evolution wrote: On 7 Oct 2016, at 07:39, David Hart via swift-evolution > wrote: Hello community, From all the proposals which has gone into Swift 3, *[SE-0025] Scoped Access Level* is the

Re: [swift-evolution] private & fileprivate

> On 7 Oct 2016, at 07:39, David Hart via swift-evolution > wrote: > > Hello community, > > From all the proposals which has gone into Swift 3, [SE-0025] Scoped Access > Level is the only one I’m having second thoughts about. Before launching a > discussion around

Re: [swift-evolution] private & fileprivate

Do language ships ever sail? New POV’s should always be welcome. Just spit it out… Rien. > On 07 Oct 2016, at 08:39, David Hart via swift-evolution > wrote: > > Hello community, > > From all the proposals which has gone into Swift 3, [SE-0025] Scoped Access >

[swift-evolution] private & fileprivate

Hello community, >From all the proposals which has gone into Swift 3, [SE-0025] Scoped Access >Level is the only one I’m having second thoughts about. Before launching a >discussion around it, I’m curious to know if it's worth discussing it or if >the “ship has sailed”. As the plan is to allow