[swift-evolution] [Proposal] Property behaviors

[Joe Groff]

> On Jan 25, 2016, at 6:40 PM, Jordan Rose <jordan_rose at apple.com> wrote:
> 
> Finally caught up. :-) I like this latest version better than the two previous versions, but I kind of think that if behaviors can't emulate "lazy", we've failed. Nothing has a stronger motivation than that at this point in time; there's lots of cool things we could use behaviors for, but you can still write all of them with a wrapper type.

Not sure what you mean. It can.

> Deferred questions along that line of thought:
> - Can a behavior optionally have an initial value, and provide its own default otherwise?

Not yet.

> - Can a behavior optionally have an initial value, and require phase-1 initialization in an instance initializer otherwise?

Not yet.

> - Does a behavior with no initializer requirements not allow initial values?

Yes for now. I'm trying to keep the initial model simple. Rounding out the initialization model is a design discussion unto itself.

> Other comments on the actual proposal:
> 
> - Is 'Self' the static type or the dynamic type of 'self'? That is, what does 'Self()' do in a class with subclasses?

Good question.

> 
> - Someone else brought this up, but can I override behavior methods in a subclass with a new behavior? Can I invoke super's implementation of those behavior methods?
> 
> - Can I wrap a superclass property with a behavior? This version of the proposal doesn't have 'base', so I assume the answer is no, but that knocks out the other special-case language feature that was to be replaced by the general feature.

We're not done yet; this is just version 1. I'm subsetting composition out, since that's also an interesting discussion unto itself. You ultimately ought to be able to wrap a superclass property in new behaviors, but I don't see how you could replace a behavior without violating the superclass's encapsulation. Chaining to super behavior members also feels a bit overly intimate; do you have a use case in mind?

> - I'm not sure why changing the storage in a public behavior is inherently fragile, unless they are public. I think it's more that behaviors are all inlined, so if the implementation changes there's no guarantee that existing users of the behavior are using the updated version. That means changes aren't breaking, just not guaranteed universal.

Maybe fragile is the wrong word—'inlineable' is more what I meant.

> - Like many others I'm still not happy with the syntax—either the declaration syntax or the use syntax. I agree that it looks like a subscript and has nothing to do with other square brackets in the language…although there are only so many sigils. (Okay, I guess it's vaguely like capture lists.)
> 
> - I don't like that the name of the behavior shows up in the member access. I feel like the behavior of "Resettable" or "Observable" could be implemented by different behaviors, and I would want the freedom to resiliently change that while keeping the same public interface. Further down that direction lies "behavior protocols", though, which is way too much complexity for this…
> 
> - Nitpick: why are "willSet" and "didSet" mutating? (I know they are now, but that seems like the wrong interface once we have something more flexible.)
> 
> I think that's all I have for now. 

-Joe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160125/0463f537/attachment.html>