[swift-evolution] [Proposal] Property behaviors
Joe Groff
jgroff at apple.com
Thu Dec 17 12:52:37 CST 2015
> On Dec 17, 2015, at 10:26 AM, David Owens II <david at owensd.io> wrote:
>
> The functionality looks like it is something that is definitely required to reduce the boiler-plate that Swift currently requires. However, this seems like a specific instance of a more general problem. For example, I run into a similar problem with working with other constructs, such as enums, where I want to provide specific “behaviors” for them that is just a bunch of boiler-plate code.
>
> It seems like this proposal could be a starting place to start flush out what a macro/preprocessor/boiler-plate-reducer would look like in Swift. As such, I would like to see a syntax that could be extended beyond properties. Maybe this system is limited in scope to only allow this generation in specific contexts, like this property behavior, especially to scope this proposal down.
>
> The short of it: I like the idea and it seems expandable to future concerns if syntax like attributes are used. And like you mentioned, these could be generate errors when used in the wrong contexts, such as lacking @behavior_function, or its equivalent.
Yeah, Python decorators came up as another potential model when we were discussing this internally, since it would be similarly useful to be able to concisely wrap function bodies in memoizing/logging/proxying logic. Properties were my first target, since we already have too many special-purpose features cooked into the language, and endless feature requests for new ones. I honestly haven't thought about generalization much; at first blush, I'm concerned that the details of what you'd want to plug in to in a "function behavior" is quite different from what you want in a property. Mutable properties have a bit of non-obvious internal complexity in the language model which influences this proposal, to keep copy-on-write efficient while still allowing for abstraction. That complexity probably wouldn't be necessary for other things like enum cases or function decorators.
-Joe
More information about the swift-evolution
mailing list