SE-0030 Property behaviours


(Anton Zhilin) #1

An idea for future directions (quite obvious, but not yet discussed).
Extract current computed properties into a library behaviour, that is,
convert

var x: Int {
   get { ... }
   set { ... }
}

To

@computed var x: Int {
   get { ... }
   set { ... }
}

This is closely related to discussion of removal of `if let x = ...` in
favor of `if let x? = ...`
Intentions are the same: remove extra entities and simplify grammar.

What do we do with read-only computed properties? Defaulting set accessor
to fatalError() is not really a solution.

P.S. The initial email was blocked by Mailman, don't respond to it, please.


(Brent Royal-Gordon) #2

What do we do with read-only computed properties? Defaulting set accessor to fatalError() is not really a solution.

Behaviors already support read-only getters—you just omit the set {} block.

···

--
Brent Royal-Gordon
Architechies


(Radek Pietruszewski) #3

I’m not sure this is a great grammar simplification since we still need the { get { }; set { } } syntax…

And computed properties seem like quite a basic, almost fundamental feature (unlike lazy, @NSCopying etc).

This is closely related to discussion of removal of `if let x = ...` in favor of `if let x? = ...`
Intentions are the same: remove extra entities and simplify grammar.

A discussion which, AFAIR, was quickly put to rest, since the Swift team tried it and people didn’t like the change.

— Radek

···

On 25 Feb 2016, at 14:14, Антон Жилин via swift-evolution <swift-evolution@swift.org> wrote:

An idea for future directions (quite obvious, but not yet discussed).
Extract current computed properties into a library behaviour, that is, convert

var x: Int {
   get { ... }
   set { ... }
}

To

@computed var x: Int {
   get { ... }
   set { ... }
}

This is closely related to discussion of removal of `if let x = ...` in favor of `if let x? = ...`
Intentions are the same: remove extra entities and simplify grammar.

What do we do with read-only computed properties? Defaulting set accessor to fatalError() is not really a solution.

P.S. The initial email was blocked by Mailman, don't respond to it, please.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Anton Zhilin) #4

var behaviour computed<Value>: Value {
    accessor get() -> Value
    accessor set(newValue: Value) {
        fatalError()
    }
    get {
        return get()
    }
    set {
        set(newValue)
    }
}

There seems to be no way we can disable `set` if `accessor set` is
defaulted, based on current property behaviour rules. We could add both
@computed and @computedReadOnly, for example.

Behaviors already support read-only getters—you just omit the set {} block.

And I've just discovered a gaping hole in this design: mutability of
`accessor get` cannot be automatically forwarded to `get`. We would have to
always declare mutable `get`. Or have @computed, @computedMutable,
@computedReadOnly, @computedMutableReadOnly.

So computed properties should remain untouched for now, I guess.