[swift-evolution] [Proposal] Property behaviors

[Jordan Rose]

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.

Deferred questions along that line of thought:
- Can a behavior optionally have an initial value, and provide its own default otherwise?
- Can a behavior optionally have an initial value, and require phase-1 initialization in an instance initializer otherwise?
- Does a behavior with no initializer requirements not allow initial values?

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?

- 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.

- 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.

- 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. 

Jordan


> On Jan 22, 2016, at 16:33, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I've revised my proposal again based on more feedback. Syntax changes include:
> 
> - adopting John McCall's declaration-follows-use syntax for behavior declarations. I think this looks nice and provides a reasonable framework for binding all the fiddly bits of a property, such as its type, name, and initializer.
> - changing the proposed syntax for behavior member lookup to 'property.[behavior].member', as suggested by Tal Atlas and others. I think this has a nice symmetry with the `var [behavior]` declaration syntax, and doesn't occupy any new sigils. On the other had, Curt Clifton and others have raised the point that it could be mistaken for a subscript at a glance.
> 
> To reduce the complexity of the initial feature review, I've also removed many of the bells and whistles from this initial version for separate consideration. For now, I'm saying initializer requirements are always "eager" (can't refer to self) and always inline-initialized. This imposes some inconvenience on some use cases, but is an additive feature. I've also left behavior composition, extending behaviors, overloading behaviors, and name binding as future extensions. Joe Pamer raised some design and technical challenges around how type inference should work with behaviors too, which I think deserve focused discussion, so I'm sidestepping those issues by starting out saying properties with behaviors always need an explicit type. Here's the updated proposal:
> 
> https://gist.github.com/jckarter/66ae8fb361c0d57b3227
> 
> And for reference, previous iterations:
> 
> https://gist.github.com/jckarter/50b838e7f036fe85eaa3
> https://gist.github.com/jckarter/f3d392cf183c6b2b2ac3
> 
> -Joe
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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