<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">We have this, actually! It's spelled "private(set)" on the property.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Jordan</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 4, 2015, at 11:48 , Evan Maloney <<a href="mailto:emaloney@gilt.com" class="">emaloney@gilt.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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.<div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class=""><div style="margin: 0px; line-height: normal; font-family: 'Input Mono';" class=""> <span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">public</span> <span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">var</span> authenticationValidUntil: <span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">NSDate</span>? {</div><div style="margin: 0px; line-height: normal; font-family: 'Input Mono'; color: rgb(79, 129, 135);" class=""><span style="" class=""> </span><span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">return</span><span style="" class=""> </span>_authenticationValidUntil</div><div style="margin: 0px; line-height: normal; font-family: 'Input Mono';" class=""> }</div><div style="margin: 0px; line-height: normal; font-family: 'Input Mono';" class=""> <span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">private</span> <span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">var</span> _authenticationValidUntil: <span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">NSDate</span>?</div></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">For example:</div><div class=""><br class=""></div><div class=""><div style="margin: 0px; line-height: normal; font-family: 'Input Mono';" class=""> <span style="color: rgb(187, 44, 162);" class="">var</span> authenticationValidUntil: <span style="color: rgb(112, 61, 170);" class="">NSDate</span>? { <span style="color: rgb(187, 44, 162);" class="">public get, private set </span>}</div></div><div class=""><br class=""></div><div class="">This would result in a public getter, while the implementer could still set the value of the property.</div><div class=""><br class=""></div><div class="">Curious to get your thoughts on this.</div><div class=""><br class=""></div><div class="">Regards,</div><div class=""><br class=""></div><div class="">E. Maloney</div><div class="">Gilt Groupe</div><div class=""><br class=""></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=ZEz4qHYnXhPr3bBPu-2FxP4tN3HfWKL-2FtJpqkQ0gkOVSBgR5C72gsbnEoyI0eZEqTJSXZsN3pkj1tMHE7UyKiRykZY2dkbCY35ikJH62OMLqyLx1fG0xFHPUH7M4cB1bQ-2FLcKjT9778qwjRtiWbuYy4JpfxzstrIDaieBbpf-2FRnES9XFPCoR3oJUgFBxRM2mD2KgllQ1eS0G0UxFusGBN-2BdWhJvMjL8ciG928uXubzkt8-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
</div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>