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

[Evan Maloney]

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 at 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 at gilt.com <mailto: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 <mailto: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/8b2e23c0/attachment.html>