Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

I am opposed to any change to the current access level system. What we have now is simple, approachable and handles all real cases for limiting or granting access. Any additions will just serve to complicate the current system without sufficient offsetting benefit. Further additions will

Re: [swift-evolution] SE-0025: Scoped Access Level, next

Check out the `testable` attribute: https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Attributes.html#//apple_ref/doc/uid/TP40014097-CH35-ID347 Lots of examples if you type `swift testable` into your favorite search engine. On Fri, Apr 1, 2016 at

Re: [swift-evolution] SE-0025: Scoped Access Level, next

I’m fairly sure what you are asking for already exists with @testable: https://www.natashatherobot.com/swift-2-xcode-7-unit-testing-access/ > On 01 Apr 2016, at 23:04, John Heerema via swift-evolution > wrote: > > I’m a fan of test-driven development. > I use it

[swift-evolution] SE-0025: Scoped Access Level, next

I'm a fan of test-driven development. I use it myself, and teach it to students and colleagues. One of the nice things about Swift 1.0 was that it was easy to write module tests. When access controls were introduced into Swift, I found that many functions and objects that had no genuine need

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

Em sex, 1 de abr de 2016 às 01:31, Ilya Belenkiy via swift-evolution < swift-evolution@swift.org> escreveu: > With these names we lose consistency. The current scheme makes it very > clear that each next level is a subset of the previous level. With > "internal", fileprivate looks out of place. >

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

In terms of alternatives to fileprivate, I just want to chime in to say that "filewide" seems to be a term that people seem to reach for in describing this scope, based on a quick Google search. It's readable, IMO, and definitely an adjective, it breaks no new ground in terms of coining a new

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

How about: notprivateatall notveryprivate mostlyprivate stayout!!!private Sorry. April fools.. :-) > On Apr 1, 2016, at 8:00 AM, Ross O'Brien via swift-evolution > wrote: > > "or within my whole program (external)". That caused a double-take on its own. > >

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

"or within my whole program (external)". That caused a double-take on its own. external things are not within, they are outside. 'external' could be a replacement term for 'public', not for 'internal'. This may well be a subjective thing, but I don't think in files, I think in modules because

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

A new type is implicitly internal to a module. Implicitly specifying it as 'external' is just plain confusing. On Fri, Apr 1, 2016 at 3:01 PM, Sean Heber via swift-evolution < swift-evolution@swift.org> wrote: > I know this is kind of winding down, and there seems to be a kind of > begrudging

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

I know this is kind of winding down, and there seems to be a kind of begrudging acceptance of “fileprivate” emerging (perhaps due to fatigue), but I still really don’t like it so I’m going to toss out my current favorite configuration and try to stop caring and defer to the core team to make an

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> I’ve seen a number of concerns on this list about moduleprivate, and how it > penalizes folks who want to explicitly write their access control. I’ve come > to think that there is yes-another possible path forward here (which I > haven’t seen mentioned so far): > > public > internal >

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

With these names we lose consistency. The current scheme makes it very clear that each next level is a subset of the previous level. With "internal", fileprivate looks out of place. We have several goals for all the names: 1) obvious 2) using standard terms 3) short 4) consistent This discussion

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

I have to say, I'm not very happy with the progress of this topic .. Let me explain: I'm Swift user from day 1. A few weeks after, even with the limitations of language, had an application in production. One of the "cool" features that regularly use in my application is the "file private" access

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> So, proposal one (and 1b), more technical sounding > > public > internal (or intramodule) > intrafile > private `intrafile` and `intramodule` sound esoteric to me. I like these ones better: public moduleonly fileonly private//aka, scopeonly? unfortunate that this isn’t automatically clear

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

I'd be okay with this, but I do think having a private and fileprivate will confuse people considering they both have private in their names Brandon Sent from my iPad > On Mar 31, 2016, at 12:22 AM, Chris Lattner via swift-evolution > wrote: > >> On Mar 23, 2016,

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

Or maybe we could just abolish of file-private. It's not like it'd be 100% gone: private declarations at the root of a file will always be equivalent to file-private. For non-root things that need to be accessible within the file you can use `internal`, which is more accessible than before but

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

I like : - public - modulewide or moduleprivate or internal - filewide or fileprivate - private I really dislike interfile because the word exists and means something else I dislike intermodule, inmodule and infile because I don't find them intuitive at all. I prefer the -wide flavors because

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> public > internal > interfile > private Linguistically, I really like this direction. 'interfile' is one word, it reads as an adjective, it can be used in conversation (this has interfile visibility), and it's clear about where its visibility ends. It just doesn't mean what you think it means.

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

If not interfile I can suggest infile again too. > On Mar 31, 2016, at 12:38 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> I’ve seen a number of concerns on this list about moduleprivate, and how it >> penalizes folks who want to explicitly write their

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> I’ve seen a number of concerns on this list about moduleprivate, and how it > penalizes folks who want to explicitly write their access control. I’ve come > to think that there is yes-another possible path forward here (which I > haven’t seen mentioned so far): > > public > internal >

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

Perhaps it's because I'm not a native English speaker, but interfile doesn't read well at all to me whereas fileprivate is crystal-clear. > On 31 Mar 2016, at 08:21, T.J. Usiyan via swift-evolution > wrote: > > public > internal > (fileprivate | interfile) > private

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

I love those. And internal corresponds to the meaning it has in other languages. +1 > On 31 Mar 2016, at 06:22, Chris Lattner via swift-evolution > wrote: > >> On Mar 23, 2016, at 10:13 PM, Chris Lattner wrote: >> How about we continue this

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

public internal (fileprivate | interfile) private Either choice is fine with me On Thu, Mar 31, 2016 at 11:33 AM, Jesse Squires via swift-evolution < swift-evolution@swift.org> wrote: > I really like this. +1 for the following: > > public > internal > fileprivate > private > > -Jesse > > On

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

I really like this. +1 for the following: public internal fileprivate private -Jesse On Wed, Mar 30, 2016 at 9:22 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > On Mar 23, 2016, at 10:13 PM, Chris Lattner wrote: > > How about we continue this

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

One bonus it is a real word so autocorrect doesn’t fix it! I checked the dictionary and there are no negative or misleading meaning. It is a verb though, this is not being used as a verb in this case. http://www.dictionary.com/browse/interfile >

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

Looks good to me. -Thorsten > Am 31.03.2016 um 06:22 schrieb Chris Lattner via swift-evolution > : > >> On Mar 23, 2016, at 10:13 PM, Chris Lattner wrote: >> How about we continue this trend, and follow other existing Swift keywords >> that

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

On Mar 23, 2016, at 10:13 PM, Chris Lattner wrote: > How about we continue this trend, and follow other existing Swift keywords > that merge two lowercase words (associatedtype, typealias, etc), and use: > > public > moduleprivate > fileprivate >

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

One more possibility: public intermodule interfile private slightly longer but reads well. > On Mar 30, 2016, at 9:11 PM, Paul Ossenbruggen wrote: > > Ok speaking up, not a fan of fileprivate and moduleprivate because > > 1) very long > 2) doesn’t flow. > 3) not really

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

Ok speaking up, not a fan of fileprivate and moduleprivate because 1) very long 2) doesn’t flow. 3) not really private. I would be fine with filewide and modulewide and infile and inmodule with a slight preference for the infile and inmodule because it is shorter and conveys the same

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> public > filewide > modulewide > private > > Don’t bother me because they seem to be part of the word. The way > “nationwide” does, they are made up words but intent is clear. I could live with filewide and modulewide instead of fileprivate and moduleprivate. I still prefer the latter

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

public filewide modulewide private Don’t bother me because they seem to be part of the word. The way “nationwide” does, they are made up words but intent is clear. OK violating my own statement of only having single words, but very short words. How about? public inmodule infile private I

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

I wonder if perhaps it would be clearer if public was used for indicating something was published, even if it is published to a restricted set: public(#all)- expose outside the framework, shortened to public public(#module) - exposed module-wide, default if omitted public(#file)

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

I know that it’s been suggested a while back, but what is/was the reasoning for rejecting: public module (same as internal in Swift 2.2) file (same as private in Swift 2.2) private It seems pretty simple, clear, and understandable. It doesn’t make itself very useful as search terms (module or

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> On Mar 30, 2016, at 16:30, Brent Royal-Gordon wrote: > > While working that out, I also came up with a new suggestion for keywording > if we keep just these four levels and don't generalize `fileprivate` into an > "internal, with limitations" mechanism: > > * public

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> On Mar 30, 2016, at 15:20, Brent Royal-Gordon wrote: > >> Now, it is a very useful feature! Apple, of course, does this all the time >> with its "SPI". But I think the right form of the feature is to be able to >> tag a bunch of public declarations as "SPI" or

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> Now, it is a very useful feature! Apple, of course, does this all the time > with its "SPI". But I think the right form of the feature is to be able to > tag a bunch of public declarations as "SPI" or "limited" or "limited to group > 'X'" or possibly even "limited to module 'X'", and then

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

How about public, private, private(#file), and private(#module)? At a later date, if needed, private(S1, S3, ...) could be added. This would be a minimal change and not stop an extension in the future if requested. On Thursday, 31 March 2016, James Campbell via swift-evolution <

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

What about local for a file only or scope definition ?  Sent from Supmenow.com On Wed, Mar 30, 2016 at 12:39 PM -0700, "Jordan Rose via swift-evolution" wrote: Ah, sorry! Those are all clear to me; it's the possibility of writing some other module name

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

Ah, sorry! Those are all clear to me; it's the possibility of writing some other module name there that would have the wrong implications. Jordan > On Mar 30, 2016, at 12:38 , Ross O'Brien wrote: > > Damn, and I thought it was clear all this time that

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

Damn, and I thought it was clear all this time that 'private(module)', or 'private(#module)', or 'moduleprivate', meant that the symbol is visible only inside the module. It's always been a suggested replacement specifier for 'internal'. On Wed, Mar 30, 2016 at 6:33 PM, Jordan Rose via

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> On Mar 29, 2016, at 17:47 , Brent Royal-Gordon wrote: > >> If Scala style access modifiers were adopted for Swift then a private(file) >> modifier would also be necessary to give the current private functionality. > > I could imagine having these options: > >

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

Associatedtype won’t be used nearly as often as these operators, I support the rational there but not in this case as it will be seen far more often. - Paul > On Mar 30, 2016, at 8:28 AM, Ilya Belenkiy wrote: > > I understand. The same is true about associatedtype. My

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

I understand. The same is true about associatedtype. My iPhone just suggested it as a one word completion! I think the same will happen with these names. Chris Lattner already described the rationale in this thread, so I won't repeat it. I also originally wanted short names, but I think that we

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

The scala idea is interesting, has anyone used it extensively to understand how well it works in practice? Is it too fiddly? Do you spend too much time thinking about access levels. > On Mar 29, 2016, at 5:47 PM, Brent Royal-Gordon via swift-evolution > wrote: >

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

I understand the desire to wrap this up as it has gone on for a long time. I just don’t like the length and readability of the moduleprivate and fileprivate names (and how auto correct is always “fixing” it for me when I try to write about it). As I mentioned these will likely be used very

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

So, just so I'm understanding correctly what the new system would be (taking into account Chris Lattner's comments). A symbol specified as 'public' is visible outside the module. A symbol with no specifier, or specified as 'moduleprivate', is visible only within the module, but anywhere within

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

I believe we will need another non-type access level if frameworks are ever divided into submodules. -DW > On Mar 30, 2016, at 7:13 AM, Ilya Belenkiy via swift-evolution > wrote: > > I am not sure if we will ever get another access level. If we do, great, but >

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

On Mar 29, 2016, at 20:47, Brent Royal-Gordon via swift-evolution wrote: >> If Scala style access modifiers were adopted for Swift then a private(file) >> modifier would also be necessary to give the current private functionality. > > I could imagine having these

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

>> On Mar 29, 2016, at 13:54, Chris Lattner via swift-evolution >> wrote: >> >> On Mar 25, 2016, at 10:37 AM, Kevin Lundberg via swift-evolution >> wrote: >> I use the file-private scope a fair amount for top-level constants that are >>

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

Yes, #module would be a nice addition and I like the #file and #modules scope names since they can't clash with user defined names. -- Howard. On 30 March 2016 at 11:47, Brent Royal-Gordon wrote: > > If Scala style access modifiers were adopted for Swift then a >

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> If Scala style access modifiers were adopted for Swift then a private(file) > modifier would also be necessary to give the current private functionality. I could imagine having these options: public // visible to all everyone

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

Scala has a sophisticated and interesting access level that might well be good fit to Swift (since the two languages are very similar), e.g Swiftizing some Scala: class society { class professional { class Executive { private(society) var friends = ... private(professional) var workDetails =

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

I'm kind of late to this thread, so if my argument has been brought up before, please just ignore me: I know naming the modifiers `module` and `file` have been suggested already, and those were dismissed as being to broadly named. Would these modifiers stand on their own, I'd agree with this

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

If someone sees public and external in different places while learning the language they would be curious to see what the difference is. The first time I saw internal in swift, I looked it up. It was not immediately apparent from the name what it meant from then on, there was no confusion. This

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> On Mar 28, 2016, at 6:38 PM, Matthew Johnson via swift-evolution > wrote: > >>> On Mar 28, 2016, at 18:20, Matthew Judge wrote: >>> >>> There are two different questions that we keep bouncing back and forth >>> between. Given: >>> >>>

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> On Mar 29, 2016, at 10:18 AM, Jordan Rose wrote: > > A good handful of people already enumerated several cases where file-based > scoping is useful, and I very much agree. Leaking helper operations across an > entire module just because they can't be lexically scoped,

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

On Mar 25, 2016, at 10:37 AM, Kevin Lundberg via swift-evolution wrote: > I use the file-private scope a fair amount for top-level constants that are > intended to be used within the file, possibly across types. Doing things this > way is more concise than embedding

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

Sent from my iPad > On Mar 29, 2016, at 12:18 PM, Jordan Rose via swift-evolution > wrote: > > >>> On Mar 29, 2016, at 10:14 , David Owens II wrote: >>> >>> Additionally, we think we can get away with renaming "private" because most >>> current

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> On Mar 29, 2016, at 10:14 , David Owens II wrote: > >> Additionally, we think we can get away with renaming "private" because most >> current uses of "private" (file-scoped) declarations are within the same >> (brace-bound) scope anyway; > > A quick look through my code

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> Additionally, we think we can get away with renaming "private" because most > current uses of "private" (file-scoped) declarations are within the same > (brace-bound) scope anyway; A quick look through my code bases verifies that this is true with my small sample of code. The only outliers

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

I checked this out when I was making my lists. It's a very simple solution, but I feel like "internal (module-scoped) method on a public class" is a common enough use case that we wouldn't want to rule it out, or force the user to write a separate extension. Jordan > On Mar 29, 2016, at 8:12

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

FWIW, Ceylon uses only a lexical access level like in the proposal (as I understood it): program elements which are visible only inside the scope in which they are defined, and program elements which are visible wherever the thing they belong to (a type, package, or module) is visible. In

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

How is flexibility desirable? Why is it important to me, if I decide that a given class should only be visible at 'internal' scope, that the meaning of 'internal' should be subject to change in future versions of Swift? 'Once you know its meaning' should mean once! Right now, I use the word

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

-1, "external" can be also understood as "exported" or public. I think that the names in the updated proposal are the clearest. Also, I think that at this point we need to stop trying to come up with more names. I don't think that we will ever reach a point where everybody is happy with the names.

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> Am 25.03.2016 um 18:36 schrieb Michel Fortin via swift-evolution > : > >> Le 25 mars 2016 à 12:57, Tino Heth via swift-evolution >> a écrit : >> >> afaics this is the third time someone mentions that "file-private" is >> uncommon — so

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

I like this, it has been suggested already, single words for easy reading (just looks nicer). follows precedent in other languages for existing words, new words for new concepts. Internal gets demoted from current swift but since that was a swift concept we have more control. public - outside

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

I lean towards no as well, but this implies an infinite level of access modifiers: public private(module) // current internal private(file) // current private private(Outer) // all of the rest are the new private private(Inner) private(InnersInner) etc. The bike shedding has been focused on

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

After today's discussion, I changed the proposal back to only describe the new names (fileprivate etc.) and keep the lexical scope (I still want the immediate scope, but after Jordan's explanation that it's not standard and that other major languages don't do this, I decided to remove it.)

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> On Mar 28, 2016, at 8:32 PM, Jordan Rose via swift-evolution > wrote: > > >> On Mar 28, 2016, at 18:20, Matthew Judge wrote: >> >> There are two different questions that we keep bouncing back and forth >> between. Given: >> >> class

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> On Mar 28, 2016, at 18:20, Matthew Judge wrote: > > There are two different questions that we keep bouncing back and forth > between. Given: > > class Outer { > private var outerVar: Int > class Inner { > private var innerVar: Int > } > } > >

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

There are two different questions that we keep bouncing back and forth between. Given: class Outer { private var outerVar: Int class Inner { private var innerVar: Int } } Is outerVar visible inside Inner? To me this seems 'obvious'... Yes. Is innerVar visible to Outer? The

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

Oops here it is again: error in example On 28.03.2016, at 23:52, Ted F.A. van Gaalen wrote: Hello Joanna, seems you are quite new to programming, just kidding, so sad you’ve missed the punch card era, a lot of fun, but I cannot take you back there because my Delorean is

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

Hello Joanna, seems you are quite new to programming, just kidding, so sad you’ve missed the punch card era, a lot of fun, but I cannot take you back there because my Delorean is broken :o) Seriously, thank you for writing this, I share your opinion: > In the light of the preceding paragraphs,

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> On Mar 28, 2016, at 14:23, David Waite wrote: > > >> On Mar 28, 2016, at 2:30 PM, Jordan Rose via swift-evolution >> > wrote: >> >> P.S. Extensions do make things a little more complicated, but

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

If the following parenthesized access keywords are still on the table as an option, > On Mar 27, 2016, at 14:31, Haravikk via swift-evolution > wrote: > > public as-is, item is public/exported outside > of module >

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> I *still* don't understand your reasoning here. If a private member can be used in a member function, and in closures inside that member function, why can't it be used in a member type? The simplest answer is that it's the most private access level, and also one that doesn't create any

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

Jordan, I agree with you. IMO this is a change to the proposal that was not requested by the core team. The meaning of private was accepted was clearly the traditional meaning of lexical scope, which cleanly follows the nesting of scopes used by the other access control modifiers. The

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> Would it really make sense to allow extensions in other files to access fileprivate members/funcs? no, fileprivate is limited to the specific file in which it is used. On Mon, Mar 28, 2016 at 1:13 PM Cheyo Ximenez wrote: > Let's say that we go with > public,

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

I still don't understand your reasoning here. If a private member can be used in a member function, and in closures inside that member function, why can't it be used in a member type? I don't have a notion of "immediate lexical scope". Nothing else in Swift is only visible in the "immediate"

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

Let's say that we go with public, moduleprivate, fileprivate, scopeprivate Would it really make sense to allow extensions in other files to access fileprivate members/funcs? The inclusion of the word 'file' in the name would make it confusing that extensions have the special power to reach

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

If I may be so bold, as a programmer with over 25 years of experience, in multiple languages… Although I can see the reasoning behind "redefining" visibility scope for Swift, I find myself both agreeing and disagreeing with various aspects. Apart from Delphi, I've never come across a use of

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

Matthew, please take a look at my example with functions (it works today). In terms of scope, it should be the same with classes. I updated the proposal to restrict private to the immediate scope, so with the update, it will be Inner. Please take a look at the proposal. I tried to be very clear

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

Ilya said: > "public", "protected", and "private" have a very well defined meaning in OOP. We shouldn't redefine them without a good reason. I agree. Swift has a scope-based visibility system, not a type-based visibility system, but because Swift redefines the terms 'public' and 'private',

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

after a brief discussion, updated the proposal to limit `private` only to the immediate scope. https://github.com/apple/swift-evolution/pull/234 On Sun, Mar 27, 2016 at 10:03 PM Ilya Belenkiy via swift-evolution < swift-evolution@swift.org> wrote: > I created a pull request with the updated

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

That is not clear to me in the proposal. The proposal states: "When a function or a property is defined with `private` access modifier, it is visible only within that lexical scope." The most immediate lexical scope for innerVar would be Inner. I'm not advocating either way, just that it be

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

Maybe it's good thing that we just discussed it. After replying to Matthew, this meaning private feels so wrong that I will update the proposal to disallow this. Private should mean private. On Mon, Mar 28, 2016 at 7:27 AM Brent Royal-Gordon wrote: > > We already had a

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

The proposal is not vague. Most questions / misunderstanding is not due to the proposal itself but due to how these terms are used in other languages. It does have one unintended conclusion (the potential class injection to get access). My position on it is not to change it because it's an edge

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

On Mon, Mar 28, 2016 at 6:41 AM, Ilya Belenkiy wrote: > lexical scope is the other way around: "inner" can see "outer". For > example: > > func f() { > let outer = 0 > // f cannot use inner >func g() { >let inner = 1 >// g can use outer >} > }

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

I'd like to keep "private" to be completely private and not allow class injection to gain access, but this is an edge case that could be argued either way. I can definitely live with a pure scoped access for consistency and don't want to argue the edge case in a never ending discussion. I think

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

I understand the analogy, but I think that it doesn't apply here. If Swift was 30 years old, the argument would work, but right now there are many more people in the world who use the terms differently. Originally, I suggested using another name for backward compatibility, but I am glad that the

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

"public", "protected", and "private" have a very well defined meaning in OOP. We shouldn't redefine them without a good reason. Swift allows extensions, so "private" in its standard form doesn't work well -- you could just define an extension and get access to anything. The scope based private

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

this is more in line with other naming conventions, but the names in the updated proposal seem to match the closest to everything else in Swift. I waited for about a week to get everyone's opinion, but I think that we are past the name discussions at this point. On Sun, Mar 27, 2016 at 11:50 PM

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

lexical scope is the other way around: "inner" can see "outer". For example: func f() { let outer = 0 // f cannot use inner func g() { let inner = 1 // g can use outer } } It would work the same way for the access level. That said, I'd rather not include this in the

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> On Mar 24, 2016, at 01:13, Chris Lattner via swift-evolution > wrote: > > > >> On Mar 14, 2016, at 5:18 PM, Chris Lattner via swift-evolution >> wrote: >> Per Doug’s email, the core team agrees we should make a change here, but >>

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

I know it was suggested that it be the subject of a different thread, but it might be good to clarify how the new private is going to work (or at least what is currently envisioned). My understanding is that the new private would be: - visible only to the immediately enclosing scope -

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> I created a pull request with the updated proposal: > https://github.com/apple/swift-evolution/pull/234 As long as you're updating the proposal, I'd like to suggest you explain more explicitly the visibility of members marked with your new access level. I know I was surprised that nested

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

I created a pull request with the updated proposal: https://github.com/apple/swift-evolution/pull/234 On Mon, Mar 14, 2016 at 8:18 PM Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > Per Doug’s email, the core team agrees we should make a change here, but > would like some

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

I like the idea of protected (against extensions). However this raises the question whether extensions are also extensions of scope. Can "private(scope)" properties/functions be accessed from extensions? In your case: Is "protected" exactly like local? So it doesn't hide properties from

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> On 26 Mar 2016, at 14:11, Ross O'Brien wrote: > > Haravikk: private (type) would be the subject of another proposal. > > What this proposal is about is the following (all in one file): > > struct Foo { > func doThing() { > doPrivateThing() > } >

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

+1 for this. The only reason I was thinking 'external' was because 'module' seems to clash with the identity of the actual module but i am for the order and introducing a new word for module access. > On Mar 14, 2016, at 7:38 PM, Sean Heber via swift-evolution >

  1   2   3   >