[swift-evolution] Different types for getter and setter

[Benjamin Garrigues]

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 ?

In every language that has them, i tend to keep their use to the strict minimum, because i find that 
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.
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.

Sorry if all this has been already discussed multiple times before, i'm only following this list for a few weeks.

> Le 19 sept. 2017 à 22:56, Hooman Mehr via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> These types of unusual property behaviors could be implemented if we had property behaviors proposal 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.
> 
>> On Sep 19, 2017, at 1:36 PM, Philippe Hausler via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 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)
>> 
>>> On Sep 19, 2017, at 9:34 AM, Tony Allevato via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> There have been a couple times where I've wanted something like this:
>>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>> 
>>>> On Tue, Sep 19, 2017 at 8:16 AM Nevin Brackett-Rozinsky via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 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.
>>>> 
>>>> 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.)
>>>> 
>>>> 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).
>>>> 
>>>> Thoughts?
>>>> 
>>>> Nevin
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> 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/20170920/6cf49ff3/attachment.html>