These types of unusual property behaviors could be implemented if we had property behaviors proposal <https://github.com/apple/swift-evolution/blob/master/proposals/0030-property-behavior-decls.md> 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 > <[email protected]> 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 >> <[email protected] <mailto:[email protected]>> 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 >> <[email protected] <mailto:[email protected]>> 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 >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
