[swift-evolution] [Proposal] Property behaviors

plx plxswift at icloud.com
Wed Jan 13 19:12:00 CST 2016


Quick Q1: is it the case that `var behavior redrawing<Value where Self:UIView> : Value { … } ` would work or no? I’d assume so, but I don’t think there are any examples with a non-protocol constraint on `Self`, making it hard to tell at a glance.

Quick Q2: is there anything you can do in this scenario:

// w/in some behavior:
mutating func silentlySet(value: Value) {
  value = value // <- probably not going to work
  self.value = value // <- not right either, `self` is the behavior’s owner, right?
}

…other than change the argument name to avoid conflict?

Remark: it definitely feels a bit odd to be using both `Self` and `self` to mean something that’s neither consistent with the rest of the language nor, really, to mean `Self` (or `self`). 

I get not wanting new keywords, but this feels like it could be an economy too far; perhaps I’m misunderstanding some aspect of how it’s meant to work.

> On Jan 13, 2016, at 4:07 PM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Thanks everyone for the first round of feedback on my behaviors proposal. I've revised it with the following changes:
> 
> - Instead of relying on mapping behaviors to function or type member lookup, I've introduced a new purpose-built 'var behavior' declaration, which declares the accessor and initializer requirements and provides the storage and behavior methods of the property. I think this gives a clearer design for authoring behaviors, and allows for a more efficient and flexible implementation model.
> - I've backed off from trying to include 'let' behaviors. As many of you noted, it's better to tackle immutable computed properties more holistically than to try to backdoor them in.
> - I suggest changing the declaration syntax to use a behavior to square brackets—'var [behavior] foo'—which avoids ambiguity with destructuring 'var' bindings, and also works with future candidates for behavior decoration, particularly `subscript`.
> 
> Here's the revised proposal:
> 
> https://gist.github.com/jckarter/50b838e7f036fe85eaa3
> 
> For reference, here's the previous iteration:
> 
> https://gist.github.com/jckarter/f3d392cf183c6b2b2ac3
> 
> Thanks for taking a look!
> 
> -Joe
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



More information about the swift-evolution mailing list