[swift-evolution] [Proposal] Property behaviors

[Kevin Ballard]

Good point. I'm also inclined to say that Michel's motivating example (of a property that requires going through a `synchronized` accessor) would be better modeled just as a type Synchronized<Value> that exposes the `synchronized` accessor. No need for behaviors, you just say

var data: Synchronized<T> = ...

Behaviors are interesting because they affect how normal property access works. Properties that don't expose normal property accessors aren't really properties at all.

The only real downside to the Synchronized<Value> type is there's no way to prevent anyone from copying the value (it could be a class, but then you're paying for the overhead of using a separate object). This same limitation is also one of the problems with adding an Atomic<T> type, which is something I would dearly love to have.

On a semi-related note, we should say up-front that accessing behaviors on properties (e.g. with `foo.lazy`) _cannot_ be used to extract the behavior type as a value. The only thing you can do with this is calling a method on it or accessing a property. So no saying `let foo = data.lazy`. This limitation would be more obvious if we use an alternative behavior accessor syntax.

-Kevin Ballard

On Thu, Dec 17, 2015, at 07:00 PM, Félix Cloutier via swift-evolution wrote:
> I find that Michel Fortin's idea for subscript-less behaviors is very cool, but it also has an impact on composition. It seems to me that any behavior that doesn't implement a subscript would need to be the outer-most behavior, and it could not easily compose with any other subscript-less behavior.
> 
> Félix
> 
> > Le 17 déc. 2015 à 20:23:46, Joe Groff via swift-evolution <swift-evolution at swift.org> a écrit :
> > 
> > 
> >> On Dec 17, 2015, at 3:22 PM, Russ Bishop <xenadu at gmail.com> wrote:
> >> 
> >> My first assumption is that behaviors separate broadly into a couple of categories:
> >> 
> >> 1. Eager and uncorrelated. The logging example is a good one. A logging behavior probably doesn’t care about anything else, it just wants to run as early as possible to write the log output.
> >> 2. Ordered or correlated. These have composability issues.
> >> 3. Un-eager. didSet/willSet kind of behaviors that want to run after all behaviors of type #2 have run.
> >> 
> >> I’m trying to think if there is a way to declare the kind of behavior you have and what that would mean for composability and overriding because the compiler would be free to run all behaviors of type #1 first (unordered), then a single #2 behavior, then all the #3 behaviors (unordered), reducing the problem to specifying how ordered behaviors… er… “behave”. Perhaps in that case you’ll just have to manually implement a behavior that calls the desired behaviors. 
> >> 
> >> For overriding, as long as there is only one ordered behavior involved, all the other behaviors can execute in the appropriate “phase” without issue (all inherited eager behaviors first, etc).
> > 
> > This is a great analysis. Kevin made a similar observation. If we went in the direction of a dedicated `behavior` declaration, then it'd be reasonable to declare the behavior's kind up front, which would influence its composition behavior.
> > 
> > -Joe
> > 
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution