Looks good to me but should have some tests.

@edolstra Done

Why was this merged?!

See https://stackoverflow.com/questions/19732319/difference-between-size-t-and-unsigned-int. Please commit correct C++ code.

@coretemp we welcome feedback, but please remember that we're all people and can miss stuff, which is probably the answer to your question. If you're genuinely dismayed about it, use GitHub's UI functionality to actually comment on the line of code that runs afoul of your link. Are you talking about unsigned int n? In that case, you're probably right, but this doesn't seem worth being so dismayed over, since no realistic version string will ever get anywhere close to a point where that would matter. TBC, I'm not saying size_t wouldn't be more appropriate there, but this isn't a "holy shit, the world is ending, I must use ?! to indicate how terrible this is" kind of moment.

@coretemp I know full well the difference between unsigned int and size_t, thank you very much. I also know that nix lists are sized with unsigned int, not size_t:

OK, in that case, the issue already existed and w.r.t. to just adding this feature there is no blame for you. Since there is no comment explaining why size_t is not being used in value.hh, that's just bad programming.

@coretemp I am going to block you on my account now. Feel free to contact me through some other means if you learn to be a constructive polite member of open source communities.

Yeah, that's clearly the mature thing to do. 🙄

It would be hard to find someone qualified who wouldn't agree with me regarding how it's not bad programming to not use size_t for something which is clearly a size in C++.

Your initial reply was also overly aggressive and certainly not exemplary behavior. It would again be hard to find someone who is going to disagree on that.

@coretemp please lay off. If you want to fix the size_t thing, submit a PR, but your tone in here is combative and not welcome, and if you want to keep that sort of thing up, please take it elsewhere.