[swift-evolution] Ability to set access control independently for getter & setter of a property

Jordan Rose jordan_rose at apple.com
Fri Dec 4 13:50:09 CST 2015


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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151204/a85f0dd5/attachment-0001.html>


More information about the swift-evolution mailing list