I did a quick skim reading over the proposal, then searched for "int_fast128_t" - nothing showed up, but I also moved the cursor to the end of the page.
It looks as though they're addressed as well as they could be.
The way I use standard integers is as I described: If I want something as close to native performance as possible, the "fast" types are appropriate, etc... However, the lack of actual diagnostics here relegates determining the cause of performance issues to not just profiling, but also directly inspecting the code as well. In most cases, plain "intXXX_t" would work just as well.
> They are required to be aliases in the C++ standard. How else would
> you provide them?
What I meant there was that they are aliases for the standard types, and really not practically useful in their distinction despite the wording in the standard.
For example, one might think int64_t is an alias for __int64 in the Microsoft stdint.h, but its "typedef long long" instead. In that same header, all of the "least" and "fast" variants are identical as well. I thought the original idea behind stdint was to ensure aliases might correspond to compiler intrinsics