Ability to set access control independently for getter & setter of a property


(E. Maloney) #1

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.

Curious to get your thoughts on this.

Regards,

E. Maloney
Gilt Groupe


(Jordan Rose) #2

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.

Curious to get your thoughts on this.

Regards,

E. Maloney
Gilt Groupe

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(E. Maloney) #3

Very cool! I hadn't seen that in use anywhere; glad I sent my e-mail or I wouldn't know it exists. :slight_smile:

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.

Curious to get your thoughts on this.

Regards,

E. Maloney
Gilt Groupe

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Johan K. Jensen) #4

For reference, it can also be found in The Swift Programming Language Guide
under Access Control › Constants, Variables, Properties, and
Subscripts › Getters
and Setters
<https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/AccessControl.html#//apple_ref/doc/uid/TP40014097-CH41-ID18>
.

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. :slight_smile:

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.

Curious to get your thoughts on this.

Regards,

E. Maloney
Gilt Groupe

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution