On 21.03.22 15:37, Aleksander Alekseev wrote: >> It would not simplify things for them at all, just mess it up. >> The master copies of the .po files are kept in a different repo. >> Also, I believe that extraction of new message strings is automated >> already. > > Got it, thanks. Here is the corrected patch. It includes all the > changes by me and Japin, and doesn't touch PO files.
I think in some cases we can make this even simpler (and cast-free) by changing the underlying variable to be long long instead of int64. Especially in cases where the whole point of the variable is to be some counter that ends up being printed, there isn't a need to use int64 in the first place. See attached patch for examples.
Yes, this will work, when we can define a variable itself as long long. But for some applications: [1], [2], I suppose we'll need exactly uint64 to represent TransactionId. uint64 is warrantied to fit into unsigned long long, but on most of archs it is just unsigned long. Defining what we need to be uint64 as unsigned long long on these archs will mean it become uint128, which we may not like.
In my opinion, in many places, it's better to have casts when it's for printing fixed-width int/uint variables than the alternative.
