Currently, Swift supports a single level of access controls for properties. If a read/write property is declared as public, both the getter and the setter of that property will be publicly visible.
However, it is often the case that you need a stored property that is publicly read-only but internally or privately writeable. The current way to achieve this is by doing something like:
public var authenticationValidUntil: NSDate? {
return _authenticationValidUntil
}
private var _authenticationValidUntil: NSDate?
This seems like a lot of boilerplate to achieve a common goal. Objective-C supported a similar concept by being able to declare a property as read-only in a .h file while being able to override this as a read-write property in the .m file.
I propose being able to declare separate access controls for a property's getter and setter, wherein the setter could have more restrictive access controls than the getter.
For example:
var authenticationValidUntil: NSDate? { public get, private set }
This would result in a public getter, while the implementer could still set the value of the property.
We have this, actually! It's spelled "private(set)" on the property.
We probably will need a way to put attributes on stored property accessors, though. @objc for custom getter or setter names is an interesting one already.
Jordan
···
On Dec 4, 2015, at 11:48 , Evan Maloney <emaloney@gilt.com> wrote:
Currently, Swift supports a single level of access controls for properties. If a read/write property is declared as public, both the getter and the setter of that property will be publicly visible.
However, it is often the case that you need a stored property that is publicly read-only but internally or privately writeable. The current way to achieve this is by doing something like:
public var authenticationValidUntil: NSDate? {
return _authenticationValidUntil
}
private var _authenticationValidUntil: NSDate?
This seems like a lot of boilerplate to achieve a common goal. Objective-C supported a similar concept by being able to declare a property as read-only in a .h file while being able to override this as a read-write property in the .m file.
I propose being able to declare separate access controls for a property's getter and setter, wherein the setter could have more restrictive access controls than the getter.
For example:
var authenticationValidUntil: NSDate? { public get, private set }
This would result in a public getter, while the implementer could still set the value of the property.
Very cool! I hadn't seen that in use anywhere; glad I sent my e-mail or I wouldn't know it exists. :)
Thanks, Jordan!
···
On Dec 4, 2015, at 2:50 PM, Jordan Rose <jordan_rose@apple.com> wrote:
We have this, actually! It's spelled "private(set)" on the property.
We probably will need a way to put attributes on stored property accessors, though. @objc for custom getter or setter names is an interesting one already.
Jordan
On Dec 4, 2015, at 11:48 , Evan Maloney <emaloney@gilt.com <mailto:emaloney@gilt.com>> wrote:
Currently, Swift supports a single level of access controls for properties. If a read/write property is declared as public, both the getter and the setter of that property will be publicly visible.
However, it is often the case that you need a stored property that is publicly read-only but internally or privately writeable. The current way to achieve this is by doing something like:
public var authenticationValidUntil: NSDate? {
return _authenticationValidUntil
}
private var _authenticationValidUntil: NSDate?
This seems like a lot of boilerplate to achieve a common goal. Objective-C supported a similar concept by being able to declare a property as read-only in a .h file while being able to override this as a read-write property in the .m file.
I propose being able to declare separate access controls for a property's getter and setter, wherein the setter could have more restrictive access controls than the getter.
For example:
var authenticationValidUntil: NSDate? { public get, private set }
This would result in a public getter, while the implementer could still set the value of the property.
For reference, it can also be found in The Swift Programming Language Guide
under Access Control › Constants, Variables, Properties, and
Subscripts › Getters
and Setters
<The Swift Programming Language: Redirect;
.
You can give a setter a *lower* access level than its corresponding
getter, to restrict the read-write scope of that variable, property, or
subscript. You assign a lower access level by writing private(set) or
internal(set) before the var or subscript introducer.
—Johan
···
On Fri, Dec 4, 2015 at 8:57 PM, Evan Maloney <emaloney@gilt.com> wrote:
Very cool! I hadn't seen that in use anywhere; glad I sent my e-mail or I
wouldn't know it exists. :)
Thanks, Jordan!
On Dec 4, 2015, at 2:50 PM, Jordan Rose <jordan_rose@apple.com> wrote:
We have this, actually! It's spelled "private(set)" on the property.
We probably will need a way to put attributes on stored property
accessors, though. @objc for custom getter or setter names is an
interesting one already.
Jordan
On Dec 4, 2015, at 11:48 , Evan Maloney <emaloney@gilt.com> wrote:
Currently, Swift supports a single level of access controls for
properties. If a read/write property is declared as public, both the getter
and the setter of that property will be publicly visible.
However, it is often the case that you need a stored property that is
publicly read-only but internally or privately writeable. The current way
to achieve this is by doing something like:
public var authenticationValidUntil: NSDate? {
return _authenticationValidUntil
}
private var _authenticationValidUntil: NSDate?
This seems like a lot of boilerplate to achieve a common goal. Objective-C
supported a similar concept by being able to declare a property as
read-only in a .h file while being able to override this as a read-write
property in the .m file.
I propose being able to declare separate access controls for a property's
getter and setter, wherein the setter could have more restrictive access
controls than the getter.
For example:
var authenticationValidUntil: NSDate? { public get, private set }
This would result in a public getter, while the implementer could still
set the value of the property.