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

[Chris Lattner]

On Feb 11, 2016, at 10:30 AM, Joe Groff <jgroff at apple.com> wrote:
>> In any case, I think we should just pick a syntax, land the feature, and keep bikeshedding on it through the end of Swift 3 :-)
> 
> Agreed.

WFM.

> 
>> I understand the need to specifying whether the getter/setter and other random methods are mutating or not, but doesn’t this eliminate the difference between a var/let behavior?  Couldn’t we just say that a behavior with a nonmutating getter & setter are valid on a “let”, and that any other mutating members are unavailable on a let?  This seems like a theoretical win, though I’m not sure whether it would actually be a win in practice for any conceivable behaviors you’ve been thinking about.
> 
> I think we should subset 'let' behaviors out for the same reason we don't yet allow computed 'let' properties—right now 'let' guarantees immutability, and we don't have a way in the language to enforce that for user code. It would definitely be nice to be able to declare 'let [delayed]' and 'var [delayed]', though.

Ok, I’m fine with starting small and generalizing over time.

>> Of course, @initial_value_required is also pretty gross.  The alternative is to follow the precedent of operator decls, and introduce random syntax in their body, such as:
>> 
>> property behavior lazy<PropertyType> {
>>    initializer initValue
>>    var value: PropertyType? = nil   
>>    …
>>        value = initValue
>>    ...
>> }
>> 
> 
> Yeah, this is more like what I had proposed in previous drafts. If we go this route, I would rather use special contextual declarators like this than '@initial_value_required'-like attributes.

Agreed.  Where do you stand on taking behavior as a keyword?  Do you prefer something like the example above, or something like what you wrote in your proposal?

>> 
>> If a behavior has an init() with no arguments, then are the semantics that it is *always* run?  What if there are both an init() and an init(value : Value)?
> 
> As proposed there is no 'init(value: Value)'; we can design that later. An 'init()' with no arguments would always run at initialization time, as if:
> 
> var [behavior] x: Int
> 
> instantiated storage like:
> 
> var `x.[behavior].storage`: BehaviorStorage<Int> = `[behavior].init()`

Makes sense!

>> In "Resettable properties”, you have this:
>> 
>>   // Reset the property to its original initialized value.
>>   mutating func reset() {
>>     value = initialValue
>>   }
>> 
>> This raises the question of how “initialValue” works:  Is it evaluated once when the property is bound and the resultant value is stored somewhere (evaluating any side effects exactly once) or is it an auto-closure-like concept?  If it is autoclosure-like, what does it mean in terms of requiring “self." qualification & @noescape?
> 
> In the proposal, I say it behaves like a get-only property—it evaluates every time it's loaded.

Ok, that semantic makes sense to me.  Given that, a behavior can emulate any of the other semantics it wants.

>> 
>> to work, where the behavior requires an initial value, but that value is provided by a flow-sensitive initialization point by DI .  How does this happen?
> 
> Yeah. DI-like initialization is one of the future directions.

Ok.  That means that we can’t actually cut @NSCopying over to it yet, but I’m fine with tackling that later.

>> 
>> This makes me vaguely uncomfortable, given that “changeObserved” has undeclared type requirements that are only diagnosed when the behavior is instantiated.
> 
> That was an oversight. In reality you'd have to declare:
> 
> public behavior var [changeObserved] _: Value = initialValue
>   where Value: Equatable {

Ok, great.

I’m very curious where you stand on the syntax of the behavior decl, because this decl (as one concrete example) seems like it would be *much* nicer as:

public var behavior changeObserved<Value : Equatable> {

>> Can property requirements in protocols have behaviors on them?
> I think not.

Ok, please mention that, thanks!

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160211/9b5402d5/attachment.html>