Note that size_t is not always size_type, but I haven't replaced your other usages of size_t throughout the codebase (I can upon request).
Some details:
Further discussion:
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--021abf342d371248e50ceaed478a90ca-->
See the guideline for information on the review process. A summary of reviews will appear here.
We don't support WIN16 or DOS, etc, so your rationale from the stackoverflow link does not apply. The paper you linked to talks about something else. I haven't looked at the other links.
Given that this doesn't change behavior or likely even the resulting binary, this qualifies as a style change:
Thank you for your contribution. While this stylistic change makes sense on its own, it comes at a cost and risk for the project as a whole. The weak motivation for the change does not justify the burden that it places on the project. A burden could be any of the following:
For more information about refactoring changes and stylistic cleanup, see
Generally, if the style is not mentioned nor enforced by the developer notes, we leave it up to the original author to pick whatever fits them best personally and then leave it that way until the line is touched for other reasons.
Let us know if you have any questions.