[swift-evolution] [Proposal] Property behaviors

[Brent Royal-Gordon]

>> That parameterization could be achieved, somewhat more verbosely, using an accessor 'key { return "id" }'. If behaviors could be parameterized in-line, I wouldn't do it by passing the params to `init`, since that again imposes the need for per-instance storage to carry `key` from the behavior initialization to the property implementation.
> 
> Thinking about this more, maybe the need for instance storage could be avoided by letting behaviors declare `static` properties. It's likely that behavior instantiations will need some global data structure, at least in debug builds, to collect their parameterizations from property decls using the behavior. It'd make sense to put some of that global structure under the behavior's control. We'd still potentially need a separate `static init()` to initialize that storage once per declaration, rather than once per instance.

That's really, really, really clever. (Of course, it also means that a property will need to have some kind of existence on the type so we can attach static behaviors to it.)

I have to say, this feature of behaviors where "it's not really a type, it's a template for a bunch of stuff that gets added to your type" is a bit mind-bending. Expect to do a lot of writing in the Swift book to explain it!

> This particular use case for mapped serialization/deserialization is interesting. A potential future extension to better support it might be to let behaviors optionally bind the name of a property using them as a `String` (or other `StringLiteralConvertible` type).

Yes, I'd like that too. `key ?? propertyName` would be quite handy here.

-- 
Brent Royal-Gordon
Architechies