<div dir="ltr"><div>At the moment, the delegate pattern is just one use of protocols. We create a protocol with a set of declared functions, implemented either in a protocol extension or in the conforming type - the delegate - and another type calls functions of its delegate, notifying them when certain events occur.<br></div><div><br></div><div>I&#39;m wondering if uses of the delegate pattern can or should be made more explicitly readable. The form I have in mind creates a keyword &#39;delegate&#39;, which is used in two contexts; one to replace &#39;protocol&#39; in the declaration of a protocol intended as a delegate, and one to declare a property of the delegate type.</div><div><br></div><div>So, for example:</div><div>delegate UITableViewDataSource { }</div><div><br></div><div>and</div><div>class UITableView</div><div>{</div><div>    delegate dataSource : UITableViewDataSource</div><div>    delegate delegate : UITableViewDelegate</div><div>}</div><div><br></div><div>(I realise this example uses &#39;delegate&#39; both as a keyword and a property name, and would cause a lot of rewriting for types which generically refer to their delegates with the property name &#39;delegate&#39;, so perhaps this isn&#39;t the best choice of keyword, but bear with me, the idea may still have merit.)</div><div><br></div><div>As a term for declaring a property, &#39;delegate&#39; could be synonymous with &#39;weak var&#39;, and the type would be implicitly a non-force-unwrapped optional. I can&#39;t presently think of a type in Objective C or Swift which requires a strong reference to its delegate. (It might be preferred that the &quot;?&quot; remain explicit for readability).</div><div><br></div><div>Here are two suggestions from where delegates could benefit from being distinct types.</div><div><br></div><div>First: if the delegate pattern is observational (i.e. the type with a delegate property calls its delegate&#39;s functions as notifications), then there can be a need for multiple observers (e.g. multiple services in an app being notified that location services have been started).</div><div>(I&#39;ve tried implementing something like this; an array of references to observer-type delegates at the moment maintains strong references to all delegates, so I&#39;ve created a custom struct with a weak reference to the specific protocol&#39;s type and called &#39;forEach&#39; on a sequence of such structs; if the reference is nil, the struct can be removed from the sequence. Much as I&#39;d like this struct to be generic, I don&#39;t think I can create a generic struct with a protocol as the associated type.)</div><div>This might be declared with a keyword in the same way properties are modified with lazy / weak:</div><div>multiple delegate : CLLocationManagerDelegate?</div><div><br></div><div>Second: the delegate pattern, if applied to a group of delegates, might not be strictly observational, but might also respond in some way - a sequence of delegates could be called in turn, with candidates being asked if they can respond, returning false if they can&#39;t, true if they can.</div><div><br></div><div>Third: delegates could also form a stack. For example, in an NSXMLParser, the parser&#39;s delegate can change during parsing, as types handle their &#39;layer&#39; of parsing and then pass control to child or parent parser-delegate types. This could be simplified to calling something akin to: &#39;parser.delegate.push(childType)&#39; or &#39;parser.delegate.pop()&#39;</div><div>This might be declared like this:</div><div>stack delegate : NSXMLParserDelegate?</div><div><br></div><div>I may be combining too many ideas into one proposal, or there may be more ideas others can add. Is this worthy of discussion?</div><div><br></div><div>-- Ross O&#39;Brien</div></div>