You state that placing the UITableView protocol conformances in extensions is a misuse of protocols but I don't see where you explain why. I'm sure there are tens of thousands of instances of these extensions in app store apps.
For me having extensions for protocol conformance organizes the code and facilitates copy/paste of code from one class to another. They serve as templates in new code.
Using extensions to organize code is different from the use of extensions to add code to classes where one doesn't control the source code of the original class. I'll agree that it could be confusing to use extensions simply to organize code for a class that is all in one source file. Solving that would require a new language construct that allowed you to organize the code in a given source file. In the end whatever that thing would be would be an awful lot like the existing extensions.
Using comments to solve this problem may be an age old method but it seems an awful lot of developers believe that extensions are a better way. We're in an era where comments have gone the way of the dodo anyway.
No, actually that thought originates from the imagination of someone else: I gave a very specific example of harmful usage of extensions, but didn't write about UITableView helpers (or other protocols) in general. It might well be possible that most same-file extensions could be called misuse, but I don't think it's sensible to discuss about the original intentions for that feature and the history of that custom.
That is my key point: It's a belief that "it's better to put every protocol conformance into separate extensions". It's not a fact backed by evidence, and so it shouldn't be treated as such.
My belief is that comments are still very valuable (at least the headerdoc-flavor), but although I think there is some pretty compelling advantage, I don't feel offended by different opinions.
Maybe it was the lack of context that led to confusion, since you only said "here's an example of misuse" and posted a code snippet, so other readers like myself attempted to guess which patterns in that snippet were the alleged misuse. To help us better understand, could you be more specific about what in that code snippet you consider to be misuse? Are there concrete ways that it could be changed that still use extension-based organization that removes the misuse?
That's exactly what's happening in the example — and despite this paragraph, people seem to be blind to see that implementations reside in the "wrong" extensions.
You could simply put all UITableViewDatasource methods in the UITableViewDatasource extension, and the UITableViewDelegate methods in the UITableViewDelegate extension to remove the misuse that is (hopefully) undisputed — but I consider the pattern in question to be universally harmful, so moving code around only fights the symptoms, not the cause.
The question itself is somewhat funny, as it shows the strong desire to proselyte (I actually had to look this up — although I've often seen "evangelize" in a technical context, the dictionary links that verb directly to religion), whereas my point is that it's ok not to use unconditional conformance extensions.
Afaik, there has never been a single serious analysis or discussion about the effects of that custom, and actually, it might already be too late for a proper trade-off.
It's wrong to call people “blind” when it was just a poor example because you need to already be very familiar with UITableView, or chase down the documentation, to understand that the methods are in the wrong extensions. And calling people cultists (cargo or otherwise), proselytes, following rituals, just “repeating claims from blog posts” etc. is both insulting and a bad way to convince anyone of anything.
Wait what? The misuse in that example is that some of the methods are in the wrong protocol extension? I guess I missed that first time around. The mistake in that code is using two protocol extensions; only one is needed. For UITableView and similar I always use a single protocol extension that adopts both protocols and would never run into the misuse you describe. Your proposed solution of using comments rather than extensions certainly won't solve the misuse you describe. As everyone knows:
// Gur pbzcvyre qbrfa'g purpx fcryyva be tenzzne be pbeerpgarff va pbzzragf.
You quote SE-0025 and SE-0169 but your opinions of them seem backwards of everyone else's. SE-0169 was an improvement of SE-0025. It mentions that "Swift encourages developers to use extensions as a logical grouping mechanism..." And that's what everyone does.
There's nothing wrong with having pet peeves. I certainly do. But on this issue I think you're in a group of very nearly one.
Actually, no extension is needed in this scenario at all ;-)
I'm pretty sure even many members of the Core Team would agree with me when I say that SE-0025 in combination with SE-0169 is a regression compared to what we had before — it's just bad for the morale to concede that compatibility won over expressiveness and elegance ¯_(ツ)_/¯.
The new private solves no real problems, but it was a significant increase in complexity (I would really appreciate if no one would launch another try to turn an opinion into a case of lese majesty… ).
That's hard to tell — but there are definitely others who are skeptical towards the unnecessary use of extensions, and there are also plausible reasons for them to stay silent:
I'm sure that the pattern in question isn't popular because of facts, but rather because of beliefs which are propagated by powerful influencers.
The prospects of success in dismantling beliefs with arguments are low, and arguing against a larger clique is tough business…
Note how few tried to present solid arguments for the use of extensions, and how many grasp for oblique rhetoric to fight opinions that aren't their own.
More insults and weird conspiracy theories. I suspect nobody is presenting “solid arguments for the use of extensions” because it's off-topic for the thread. The original question about extensions was well-answered a couple of weeks ago here:
I would suggest starting a new thread if you want to try to convince people to stop writing code in a style you don't prefer.
).