[swift-evolution] [Proposal] Property behaviors

[Matthew Johnson]

> On Jan 16, 2016, at 1:27 PM, Joe Groff <jgroff at apple.com> wrote:
> 
>> 
>> On Jan 15, 2016, at 5:54 PM, Matthew Johnson <matthew at anandabits.com <mailto:matthew at anandabits.com>> wrote:
>> 
>>> 
>>> On Jan 15, 2016, at 7:45 PM, Joe Groff via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>>> 
>>>> On Jan 15, 2016, at 6:42 AM, plx via swift-evolution <swift-evolution at swift.org <mailto: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.
>> 
>> Any thoughts about how that might work when requirements have a return value?  Or are you just referring to forwarding conformances when the protocol doesn’t have members  with return values?
> 
> I don't have a great answer in mind, unfortunately. You're right that it only really makes sense for "sink"-like protocols, where none of the requirements produce a value, or theoretically for protocols where all results are of associated types that could be optionalized. The sink protocol use case comes up all the time, though, especially with delegates and callbacks, and is one the places where ObjC's nil-messaging behavior feels legitimate.

Totally agree it could be useful in many cases.  Thanks for pointing out the associated type case.  I hadn’t considered that one but you’re right that it is theoretically possible.

I’m going to get back to wrapping up the second draft of my protocol-driven forwarding proposal soon.  I wasn’t planning to include forwarding to optional members in the core proposal, but mention that it could be added down the road.  Do you agree with holding off on that or do you think it’s useful enough to include in the core proposal?

I also hadn’t thought about forwarding from Optional<T> to T but that should be a pretty straightforward addition to the feature if it supported forwarding to optionals.

Matthew

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160116/8542c446/attachment.html>