[swift-evolution] [Proposal] Property behaviors
jgroff at apple.com
Thu Dec 17 19:22:26 CST 2015
> On Dec 17, 2015, at 4:05 PM, Alejandro Martinez <alexito4 at gmail.com> wrote:
> Really grat and interesting!
> I have a little question, would it allow to declare behaviours that accept only set and not gets? I've found myself some times wanting a "setter only" modifier for properties. It can be done with methods (see watchkit for example) but with this proposal seems like it would be nice to have it.
Set-only properties are problematic for our property model today. This proposal alone wouldn't provide them, though with Michel's proposed extension to allow a property to effectively have no accessors at all, you could implement a behavior that only exposed a set() operation on the property.
> And to point a small concern, as Matthew mentioned, It seems like some of this behaviors could reduce the actual safety of immutability with lets, specially the delayed initialization. Obviously this is better than not having any solution but would be nice to have it in the stdlib going in hand with some compiler checks.
> Looks pretty need writing "arbitrary" (in a specific form, informal protocol) code that the compiler uses to generate this. Looking forward for more freedom in this camp.
> Sent from my iPad
>> On 17 Dec 2015, at 18:26, David Owens II via swift-evolution <swift-evolution at swift.org> 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.
>> swift-evolution mailing list
>> swift-evolution at swift.org
More information about the swift-evolution