I like the idea of repurposing brackets after private to do this. I think though that it might be better if there were also a private(type) option to allow us to be explicit about it, even if we can still type just private to use it by default.
About replacing private(set), the examples you’ve given look like computed properties, and being able to put the accessibility declaration before the setter is a good option, but for stored properties I think we also need a way to specify the restriction, for example private(file: set) to enable setting the value only at the file level. This means that private on its own is by default actually private(type: get set) > On 16 Mar 2016, at 06:49, Patrick Pijnappel via swift-evolution > <[email protected]> wrote: > > Ok to summarize: > > Setter access modifiers > var foo: Int { private set { ... } } > var foo: Int { private set } > Consistent with mutating set { ... }. Arguably the current private(set) is > inconsistent. > Eliminates the odd corner case of having a double access modifier, e.g. > public private(set) var foo: Int. > It's very sensible for custom getters/setters (top case), it just requires > allowing a bodiless get/set. We already kinda do this in protocols. > > Access modifier keywords > public/private(module)/private(file)/private > It's not clear from the keywords how restrictive local/private/internal are, > while private(module) and private(file) are obvious. This makes a declaration > either public, or private to a certain scope. Arguably e.g. > public/module/file/declaration has similar benefits but they aren't as > clearly access control related as a keyword (e.g. module could just as well > be declaring a module). > private(module) and private(file) are relatively long, but the longest – > private(module) – is rarely used (outside the standard library) as it's the > default. Most uses of the old private are more appropriately done using the > new private, so private(file) would likely be used less than private. > The scheme expands very well to named submodules, e.g. if you have a > submodule named model you might limit the scope using private(model). > private(file) as opposed to private-file or private/file makes it more > consistent with the new function-like syntax for e.g. attributes. > > On Wed, Mar 16, 2016 at 11:26 AM, Ross O'Brien via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > It's occurring to me, reading these recent posts, that we have two orthogonal > systems of access levels. > > Swift's current access system is file based; a project file decides which > files comprise a module, and the terms 'public', 'internal' and 'private' > determine whether a property is accessible to all, accessible only within > files of the module, or accessible only within a file. (This takes on an > extra dimension as files may belong to several modules). > > The concept which began this discussion, and several of the proposed concepts > in this discussion, ask instead for a type-based access system similar to > those in other languages including Objective-C, where 'public', 'protected' > and 'private' are the terms of choice and they restrict access to a type or > subtypes. > > I think it would be confusing if Swift applied 'public' to a concept in the > file-based access system and 'private' to a concept in the type-based access > system. > > I would prefer clearer terms which actually mention the restrictions of the > level. For example, 'inherited', not 'protected', in the case of properties > accessible by a class and its subclasses; 'declaration', rather than > 'private' or 'scoped', to refer to properties only accessible within a given > type or extension declaration. > > Since, at the moment, a declaration can only occur within one file, I think > this most-restricted level has managed to pass as a level of the file-based > access system. However, if the system is ever extended, we're going to run > into new syntax decisions where we have 'private module' functions > (accessible only within the given type in the same module) trying to > communicate with 'protected file' properties (accessible only with the type > and its subtypes in the same file), and that might lead to conflicts, so > perhaps we should decide how those might be declared now. > > On Tue, Mar 15, 2016 at 11:51 PM, Jonathan Hull via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > On Tue, Mar 15, 2016 at 2:33 PM Erica Sadun <erica at ericasadun.com > <https://lists.swift.org/mailman/listinfo/swift-evolution>> wrote: >> And again, moving the access control modification to the end just doesn't >> look >> right to me or seem to enhance readability. :( > I like Shawn’s proposal better for cases where there are custom getter/setter > implementations. We should definitely be able to do: > > var foo:Int { > public get {…} > private(file) set {…} > } > > In fact, that is what I first tried to do before learning about private(set). > But without the implementations, it just seems strange to put the scoping > after the rest of the declaration (they work above because they are before > the custom getter/setter). > > I still like the idea of having the option to use parameter-like syntax for > cases where you don’t have custom getters/setters: > > private var foo:Int > private(file) var foo:Int > private(set: file) var foo:Int > private(get: global, set: file) var foo:Int > > > I guess, if we had some way to represent the standard getter/setter, that > might work too. I don’t love it, but maybe with better wording? > > var foo:Int{ > public get useDefault > private(file) set {…} > } > > Thanks, > Jon > > >> On Mar 14, 2016, at 10:22 PM, Patrick Pijnappel <[email protected] >> <mailto:[email protected]>> wrote: >> >> I like Shawn's proposal: >> >> var foo: Int { private(file) set } >> >> In fact it's probably more sensible than the current private(set) IMO. >> >> For example, we already use >> >> var foo: Int { mutating get { ... } } >> >> and not >> >> mutating(get) var foo: Int { get { ... } } >> >> On Tue, Mar 15, 2016 at 4:13 PM, Patrick Pijnappel >> <[email protected] <mailto:[email protected]>> wrote: >> I like Shawn's proposal: >> >> var foo: Int { private(file) set } >> >> In fact it's probably more sensible than the current private(set) IMO. >> >> >> While I like private(get: file, set: module) idea, I think it just gets too >> inconsistent with private(set: public) and private(set: private) (?!) >> >> On Tue, Mar 15, 2016 at 3:39 PM, Jonathan Hull via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> On Mar 14, 2016, at 8:36 PM, Patrick Pijnappel via swift-evolution >> <swift-evolution at swift.org >> <https://lists.swift.org/mailman/listinfo/swift-evolution>> wrote: >>> The only question is (as Sean mentioned) how this combines with the syntax >>> for setter access level, e.g. the current private(set). Options: >>> - Unnamed 2nd argument, giving private(file), private(file, set), >>> private(set). >>> - Named 2nd argument, giving e.g. private(file), private(file, accessor: >>> set), private(accessor: set). Less ambiguity but longer. >>> - Not using multiple arguments, but that'd probably break consistency with >>> the other unification efforts going on to make everything look like >>> function calls. >> What about the following 3 forms? >> >> private(file) //both setter and getter have file scope >> private(set: file) //setter has file scope. Equivalent to current >> “private(set)" >> private(get: module, set: file) //getter has module scope & setter has file >> scope >> >> It is a bit weird, but we should probably also allow “public" in that last >> form: private(get: public, set: module) >> >> Thanks, >> Jon >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> >> > > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
