[swift-evolution] [Proposal] Property behaviors

Joe Groff jgroff at apple.com
Sat Jan 16 13:27:18 CST 2016


> On Jan 15, 2016, at 5:54 PM, Matthew Johnson <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.

-Joe

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


More information about the swift-evolution mailing list