Since it seems that nobody would oppose to the innocuous typedef change, I think that probably it would be wise to separate that (which is not that interesting IMO but could be easily accepted) from the class approach to encapsulate serialization and arithmetic, which is clearly much more controversial. I also think that the second commit/PR would be easier to review if it was separated in smaller and more clear commits.
Please tell me if I’m going off-topic or I should move this to the mailing list, I’m trying to understand the reasoning better since I feel it can help me with my own pull requests. Although I don’t understand @laanwj’s argument that an abstraction on top of the low-level well-defined int64 type is risky or undesirable in consensus code, I can understand how changes that could potentially accept consensus are risky and therefore we must be more conservative about them, even if I disagree with the “this is completely useless for bitcoin and only useful for altchains” claim.
On the other hand, I don’t understand the “review-costs” arguments. If someone doesn’t have time to review certain change or doesn’t think it’s a priority to do so, that’s completely understandable. Not reviewing a PR for this reason and leaving it in limbo is one thing. But justifying a NACK to “cut review costs” seems at the very least premature to me. Maybe I’m missing something, but ideally NACKs should be in the form of: “This should never be merged becase A and B break X, Y and Z”, “This would be more acceptable by also implementing tests X, Y and Z” or “this PR doesn’t seem complete without also implementing A, B and C”. The more concrete the objections are, the less frustrating it is for the developer trying to contribute and the more educational for the contributor or in general to other potential contributors reading the pull requests with the objective of educating themselves on how to properly try to contribute.
Again, my apologies if this is not the place for these later observations.