[swift-evolution] [Proposal] Property behaviors

[Matthew Johnson]

Sent from my iPad

> On Dec 18, 2015, at 7:05 PM, Stephen Christopher via swift-evolution <swift-evolution at swift.org> wrote:
> 
> +1 for this proposal. I’m not clear on the syntax and need to take some time exploring it though. 
> 
> As I read the code in the proposal, it once again blurred the lines for me between property and method. It often seems to me, at an intuitive / teaching level, a property is just semantic sugar for a particular method, combined with some secret sauce to manage the backing storage for the variable. 
> 
> Someone (Doug?) mentioned getting some documentation out that would clarify the usage of property vs. method. I’d really like to see that for comparison against my own evolving heuristics. It would also be useful in discussing this proposal.
> 
>> Hi everyone. Chris stole my thunder already—yeah, I've been working on a design for allowing properties to be extended with user-defined delegates^W behaviors. Here's a draft proposal that I'd like to open up for broader discussion. Thanks for taking a look!
>> 
>> -Joe
>> 
>> https://gist.github.com/jckarter/f3d392cf183c6b2b2ac3
> … snip … 
>> Defining behavior requirements using a protocol
>> It’s reasonable to ask why the behavior interface proposed here is ad-hoc rather than modeled as a formal protocol. It’s my feeling that a protocol would be too constraining:
>> 
>> Different behaviors need the flexibility to require different sets of property attributes. Some kinds of property support initializers; some kinds of property have special accessors; some kinds of property support many different configurations. Allowing overloading (and adding new functionality via extensions and overloading) is important expressivity.
>> Different behaviors place different constraints on what containers are allowed to contain properties using the behavior, meaning that subscript needs the freedom to impose different generic constraints on its varIn/ letIn parameter for different behaviors.
> Would a set of related protocols (given some suppositions above that we could identify categories of behaviors that have similar needs) be another option?  
>> Instead of relying entirely on an informal protocol, we could add a new declaration to the language to declare a behavior, something like this:
>> 
>> behavior lazy<T> {
>>   func lazy(...) -> Lazy { ... }
>>   struct Lazy { var value: T; ... }
>> }
> I do like the idea of a behavior declaration. I find this to be relatively easy to model mentally. It fits with Swift’s general use of the type system to achieve both power and safety.
>> When do properties with behaviors get included in the memberwise initializer of structs or classes, if ever? Can properties with behaviors be initialized from init rather than with inline initializers?
>> 
>  There’s a separate discussion that mentioned allowing better control of which initializers are generated or synthesized for a given struct. There’s also been mention of a “derived” feature for adding conformance without needing to supply a separate implementation. This question seems related to me - it would be ideal if Swift had a coherent way to declare something that did not need definition because it can be generated by the compiler. In this case, to declare that a property is part of memberwise initialization. `behavior lazy<T>: memberwise {` ?

You might be talking about the initialization discussion I was involved in a week or so ago.  I'm working on a proposal that would allow for more flexible control over synthesized memberwise initialization.  I'm hoping to have a draft ready soon.

Is your example here part of a behavior declaration for lazy which states that properties with the lazy behavior may be memberwise initialized?  That's what it looks like to me.  I think syntax like that would make sense.  There are some behaviors which would need to opt out.  Somewhat ironically, I think lazy is one of them as the whole point of it is that it is not initialized immediately, but rather on first access.

> 
> Observable behaviors would not want to be precluded from initialization, but would also not want to be fired on initialization - at least that’s my first reaction. Is that true for all behaviors - that they would not want to be fired if the property is set as part of the parent type’s initialization, but only on later changes?
> 
> _______________________________________________
> 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/20151218/2c8418bd/attachment.html>