[swift-evolution] Different types for getter and setter

[Alejandro Martinez]

It would be awesome to have the property behaviours proposal being
resurrected. I'm the weird one that would like to have "set only"
properties, but obviously adding them to the language doesn't make
much sense unless we have a bigger tool to make this kind of stuff.

On Tue, Sep 19, 2017 at 11:52 PM, Benjamin Garrigues via
swift-evolution <swift-evolution at swift.org> wrote:
> 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
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>



-- 
Alejandro Martinez
http://alejandromp.com