[swift-evolution] Different types for getter and setter

Philippe Hausler phausler at apple.com
Tue Sep 19 15:36:46 CDT 2017


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 <mailto: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 <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/20170919/7267e60e/attachment.html>


More information about the swift-evolution mailing list