[swift-evolution] Delegate Method Conventions

[Brent Royal-Gordon]

> Given all of these, perhaps the best that can be done at this time is to try and get the general guidelines such that for *new* delegate APIs it’ll be possible to give them Swift names that are guideline-conformant, but can still be exposed to Objective-C (where necessary) in an idiomatic way (e.g., has the arguments in the right ordering to be a delegate/datasource/etc. call in Objective-C).
> 
> But at least at this point I’m rather dubious there’s a worthwhile transformation out there that can be uniformly applied to the “SDK delegate/datasource protocols” and lead to an overall improvement.

You know, the `tableView(_:cellForRowAt:)` format has many disadvantages, but it *does* have a few good points:

- It's extremely distinctive and unlikely to collide with normal methods.
- It clearly identifies not only that it is a delegate method, but which type it's associated with (through tableView).
- It marks all the related methods so they stick together, even in an alphabetical list.

The only exception is with unary delegate methods, which may look like either `numberOfSectionsInTableView(_:)` or `controllerWillChangeContent(_:)`. There's not really a consistent format for them in Objective-C, and they often get separated from the other methods.

So perhaps the only transformation we should do is to make unary methods more closely match multi-parameter methods:

	tableView(numberOfSectionsIn:)
	controller(willChangeContent:)

Then we can provide specific, separate guidance for delegates in the guidelines, justifying this format on the basis that the most important part of a delegate method is not actually what it does, but which type needs to call it.

-- 
Brent Royal-Gordon
Architechies