<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>Seeing this proposal for the first time and the previous messages in that thread makes me wonder : is making extensive use of getters and setters an encouraged coding style in swift ?</div><div><br></div><div>In every language that has them, i tend to keep their use to the strict minimum, because i find that </div><div>1/ properties that begin too need complex behaviors upon being set or read always end up needing additional parameters and so need to be accessed through functions.</div><div>2/ using them too much makes the code end up like a soup of state and behaviors affecting that state, whereas i like to structure my code in (at least) two distinct section with data on one side and effects on another.</div><div><br></div><div>Sorry if all this has been already discussed multiple times before, i'm only following this list for a few weeks.</div><div><br>Le 19 sept. 2017 à 22:56, Hooman Mehr via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> a écrit :<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8">These types of unusual property behaviors could be implemented if we had <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0030-property-behavior-decls.md" class="">property behaviors proposal</a> revised and implemented. How about resurrecting this for Swift 5.x? I think it will also be a useful feature that can help in the implementation of the concurrency model. To clarify the relation to concurrency: Will actors support public properties? What would a getter for such a property do? It is a similar asymmetric get/set issue, because an actor property may end up being set-only which is impossible in the current Swift property model.<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 19, 2017, at 1:36 PM, Philippe Hausler via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">There is another case to consider; similar to nil-resettable. Optional only by virtue of never being set, but setting nil values is invalid (e.g. Process.environment)<div class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Sep 19, 2017, at 9:34 AM, Tony Allevato via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">There have been a couple times where I've wanted something like this:<div class=""><br class=""></div><div class="">1) A nil-resettable property without having to resort to making it an IUO. It would be nice to have the setter able to take a T? but the getter return T, and the setter would provide a default value in the event that it receives nil.</div><div class=""><br class=""></div><div class="">2) Once I was writing an API that would keep an array of things in a property, but I also wanted a shorthand version where the user could set it with a single value and have the setter transform that into the array internally. Looking back though, that's not really defensible; it's easy enough for the call site to just add two characters and write "foo.property = [x]", and I probably wouldn't stand by that example today.</div><div class=""><br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, Sep 19, 2017 at 8:16 AM Nevin Brackett-Rozinsky via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">This may sound rather strange in the abstract, but recently I have encountered two situations where I would like to have a setter that accepts a different type than the getter returns.<div class=""><br class=""></div><div class="">In the first, the getter returns Foo and the setter should accept “@escaping @autoclosure () -> Foo”, so that the expression assigned to the property is not evaluated until it is needed. (The closure is stored in a private property, which the getter evaluates then caches the result.)</div><div class=""><br class=""></div><div class="">In the second, I want a subscript whose getter returns a concrete type (in my case, subscripting a matrix by row returns an ArraySlice<Element>) while the setter can accept something more generic (any kind of Collection with the correct Element type).</div><div class=""><br class=""></div><div class="">Thoughts?</div><div class=""><br class=""></div><div class="">Nevin</div></div>
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</blockquote></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>