Add NonCopyable trait

[yadij]

Partially implement TODO: Extract reusable paradigms into other mixins.

Future work:

• identify other classes which can use this mixin.
• identify other mixins that match this TODO

[rousskov]

FWIW, I do not understand why this PR was labeled as a feature. There is no feature being added here and that GitHub label description (i.e. "maintainer needs documentation updates for merge") does not seem to be related to anything that is going on in this PR.

[yadij]

FWIW, I do not understand why this PR was labeled as a feature.

You can see how I have been classifying some changes as "Developer Interest changes" in [https://wiki.squid-cache.org/Squid-4]. and the v5 page. IMO this one qualifies since it is most likely to become a new style requirement.

[rousskov]

FWIW, I do not understand why this PR was labeled as a feature.

You can see how I have been classifying some changes as "Developer Interest changes" in v4 and the v5 page. IMO this one qualifies since it is most likely to become a new style requirement.

To me, all changes are "developer interest changes" to some extent, so listing some of them without additional context/explanation/details does not really make sense. However, we do not need to agree on what changes you want to mark as deserving developer interest: We all can use our own change classifications, of course.

What we should agree on is how we label official PRs. Your might be implying that a PR that introduces changes that may eventually be used in some style requirements should be labeled as a "feature" PR, and such feature PR should not be merged until some vN maintainer updates some documentation (because the label is documented as "maintainer needs documentation updates for merge"). That approach does not seem like a good idea to me because

• If a PR does not propose a style requirement update, then it should not be labeled specially just because some style requirement update might be discussed and approved in the future. The two things are independent.
• If a PR does propose a style requirement update, then we may decide to label it specially (if there are good reasons for doing that), but "feature" and "maintainer" does not seem to be related to updating style requirements. We need to discuss the need and, if it is genuine, agree on a more applicable label (with a matching description).

However, I am not asserting that this is the exact approach you are proposing or using! There are probably many other ways to interpret the implications in your answer. I just do not understand what this label really means and looking at the label description (and now at "Developer Interest changes" lists) does not help.