Very good summary :) I find this option very consistent +1 > On 16 Mar 2016, at 07: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
