Different types for getter and setter

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

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
= ", 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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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@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 = ", 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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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&gt; 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@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@swift.org <mailto:swift-evolution@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 = ", 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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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@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@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@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 = ", 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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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@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@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@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@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
= ", 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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Alejandro Martinez