[swift-evolution] [Review] SE-0030 Property Behaviors

[Curt Clifton]

> On Feb 19, 2016, at 10:21 AM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Feb 18, 2016, at 9:01 PM, Curt Clifton <curt at curtclifton.net> wrote:
>> 
>> I find the naked `initialValue` “declaration" quite odd. It’s not exactly a declaration even. What are the implications for parsing? If we’re already willing to special case`initialValue` in the parser in this context, perhaps we could introduce a binding list instead, like:
>> 
>> ```
>> public var behavior lazy<Value>: Value {
>>   // Behaviors can bind the property's initializer expression with a
>>   // binding declaration.
>>   bind initialValue
>>   …
>> ```
>> Besides eliminating the odd naked “declaration”, this has the added advantage that it could be extended to `bind initialValue, propertyName`. :-)
> 
> Yeah, I'm not happy with it either. An alternative might be to bless a specifically-named `accessor` declaration, e.g.:
> 
> var behavior lazy<Value>: Value {
>   accessor initialValue() -> Value
> }
> 

Maybe we're approaching this from the wrong direction. We already have some magic identifiers within behavior declarations as described in Bindings within Behavior Declarations: `Self` for the property's host type, `self` for the property's host instance, and `newValue` as the r-value in the implementation of the `set` core accessor.

What's to keep us from just treating `initialValue` as similar magic within a behavior declaration? Is it a matter of not wanting to use additional storage if the initial value isn't referenced? If so, it seems like that could be treated as a post-hoc optimization. (Hmm, I suppose this might have resilience issues since changing implementation would change requirements, unless "we consider behaviors to be essentially always fragile" as mentioned in Future Directions.)

Or is the concern that we must communicate to users of the behavior that a property so annotated must have an in-line initializer? That's implied by the formal grammar in the proposal, where the declaration is named `initial-value-requirement-decl`. If that's the case, then I'd take the blessed accessor alternative over a naked `initialValue` declaration. For regularity, in that world it seems like properties should be able to implement the accessor directly. That is:

	@lazy var foo: Int = 4

and

	@lazy var foo {
	  initialValue { return 4 }
	}

should be equivalent.

If that's distasteful, I'd make a pitch for:

	initial-value-requirement-decl ::= 'requires' 'initialValue'

But I'll try to stop bike shedding this syntax now. I continued to be thrilled with the proposal and the directions in which behaviors can evolve.

Cheers,

Curt




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160219/0742a3be/attachment.html>