[swift-evolution] [Proposal] Property behaviors

[Stephen Christopher]

+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 {` ?

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151218/24f9bc0b/attachment.html>