[Proposal] Property behaviors


(Berik Visschers) #1

Property behaviors would allow for much more then two-phase init and flexibility on lazy. Libraries (standard or custom) would gain declarative ways of providing deep integration in other types; And, although that can be really cool, it also worries me. I'll exaggerate to make a point:

person.name = "Berik" // animates a UILabel update, updates a database record, sends an HTTP PUT, and, oh right; it does not update the name property.

This kind of side effects are possible with dynamic setters already, but property behaviors allow them to become more common. The fact that swift code generally has few side affects is a great feature. I'm basically asking for careful consideration.

Allowing "let" properties to be dynamic seems counter intuitive to me. On the one hand, using "var" for a two-phase initialized constant property is ugly, but allowing "let" variables to change over time seems too much of a sacrifice of consistency.

Berik


(Jordan Rose) #2

I think the ship has sailed on "Swift code generally has few side effects". Computed properties already imply there may be arbitrary computation behind property access. And if you mean "side effects" in the mutation / IO sense, I don't think this is any worse than what we already have. Swift does not pretend to be a pure <https://en.wikipedia.org/wiki/Purely_functional> language.

As to 'let' specifically, this actually has semantic effects: a property marked as 'let' will never change its value over its lifetime, enabling certain optimizations. On the other hand, as someone else pointed out on another thread, if the behavior for a 'let' property required mutation (say, for non-boxed lazy initialization), you'd be in trouble, since you can't modify the containing value.

Jordan

ยทยทยท

On Dec 17, 2015, at 16:46 , Berik Visschers via swift-evolution <swift-evolution@swift.org> wrote:

Property behaviors would allow for much more then two-phase init and flexibility on lazy. Libraries (standard or custom) would gain declarative ways of providing deep integration in other types; And, although that can be really cool, it also worries me. I'll exaggerate to make a point:

person.name = "Berik" // animates a UILabel update, updates a database record, sends an HTTP PUT, and, oh right; it does not update the name property.

This kind of side effects are possible with dynamic setters already, but property behaviors allow them to become more common. The fact that swift code generally has few side affects is a great feature. I'm basically asking for careful consideration.

Allowing "let" properties to be dynamic seems counter intuitive to me. On the one hand, using "var" for a two-phase initialized constant property is ugly, but allowing "let" variables to change over time seems too much of a sacrifice of consistency.

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