[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