[swift-evolution] [Proposal] Property behaviors

[Joe Groff]

> On Jan 15, 2016, at 6:42 AM, plx via swift-evolution <swift-evolution at swift.org> wrote:
> 
> One more “how will this work?” question: optionals.
> 
> Specifically, consider something like this:
> 
> // annoyingly-long protocol:
> protocol ControlExchanging {
>   typealias Context
>   func willTakeControlFrom(other: Self?, context: Context)
>   func didTakeControlFrom(other: Self?, context: Context)
>  
>   func takeControl(context: Context)
>   func cedeControl(context: Context)
>   
>   func willCedeControlTo(other: Self?, context: Context)
>   func didCedeControlTo(other: Self?, context: Context)
> }
> 
> var behavior exchangeState<Value:ControlExchanging where Self:Value.Context> : Value {
>   var value: Value
>   // here:
>   set { 
>     let oldValue = value
>     // boilerplate-choreography begins:
>     newValue.willTakeControlFrom(oldValue, context: self)
>     oldValue.willCedeControlTo(newValue, context: self)
>     oldValue.cedeControl(self)
>     value = newValue
>     newValue.takeControl(self)
>     oldValue.didCedeControlTo(newValue, context: self)
>     newValue.didTakeControlFrom(oldValue, context: self)
>   }
> }
> 
> // numerous extraneous details omitted:
> class GenericSwitchboard<Delegate:ControlExchanging were Delegate.Context == Self> {
> 
>   private(set) weak var [exchangeControl] delegate: Delegate? = nil
> 
> }
> 
> …which presumably won’t actually work unless I’ve either:
> 
> - added an additional implementation that’s typed-as `Value?` 
> - added a conditional-conformance for `ControlExchanging` to `Optional` (easy, but boilerplate)
> 
> ….both of which are workable, neither of which feels optimal (and for the latter, consider also that in many cases such conformances may generally be undesirable).
> 
> Is there a trick/detail I’m missing here?

No, I think you've got it. This seems like a general problem to me, though; it'd be nice if protocol conformances could be easily forwarded, for instance from Optional<T> to T.

> 
>> On Jan 14, 2016, at 4:05 PM, Joe Groff <jgroff at apple.com <mailto:jgroff at apple.com>> wrote:
>> 
>> Good point. Longer behavior compositions are something to consider. If behaviors have dedicated declarations instead of being applications of plain types or functions, it also becomes more reasonable to let them be used as attributes by themselves:
>> 
>> @mainThread @resettable @logged @changeObserved
>> public var foo: Int { ... }
>> 
>> I shied away from that design originally because it would be problematic to pollute the attribute namespace with potentially every function and/or type. That's less of a problem with this design.
> 
> I still like the aesthetics of your design better (until maybe when things get too long).
> 
> It might be a good general policy for proposals with syntax changes to always include at least one “heavy-duty/extreme” example.
> 
> Another argument in favor of a different positioning: it makes these kinds of things easier to write:
> 
> @resettable @changeObserved
> #if DEBUG
> @mainThread @onlyAfterViewLoaded @logged 
> #endif
> 
> …(which may or may not be a good thing).

I don't think this is currently allowed with attributes today, since the content of #if blocks is still parsed as full statement/expression/declarations.

-Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160115/75272b05/attachment-0001.html>