Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Clarify HashMap's capacity handling. #36766
HashMap has two notions of "capacity":
HashMap's code is confusing because it does a poor job of
I'm not in the compiler code much, but IIRC "span" is used during parsing to indicate a section of text (such as to report for an error). That particular usage of the word is fairly far away from this particular usage though, so there may not be a conflict in practice.
It's true that the meaning of
If you are still unhappy, I could change all uses of "capacity" within
As for adding prefixes, I think that's less effective. The use of an unprefixed "capacity" is baked into
Finally, I assume this is the review for my patch? AFAICT it's an r-, but the suggestions on how to change things to move towards an r+ are quite vague. When I r- patches for Firefox I always do my best to make it clear that (a) it is an r-, and (b) what changes are required to move towards r+, or if the patch is irredeemably flawed, make that fact clear.
That wasn't a formal review, just a comment trying to create some discussion around the problem at hand.
I think we should preferably avoid introducing another concept (span), even if it's a simple one.
I propose internal_capacity (or a variation) instead, as it has a better chance of being understood upfront. It's a trade-off of course, between disambiguating and not introducing another concept.
If you don't agree we can always wait/weight more opinions.
LGTM, only one optional nit.
This also makes reserve(0) a noop on an empty HashMap, which I think is good.