In terms of type safety, I've realized that everything descending from QEngine or, equivalently, assuming a state vector representation of a quantum computer simulation should strictly use bitCapIntOcl as its masking type, except in public method interfaces. (QUnit, for an alternative example, still strictly uses bitCapInt, for masking.)
If my original concern was whether size_t indexing of arrays would ever exceed 64 bits, the simple and clear answer is "never." The caveat is that we would expect a fully supported set of 128-bit integral types in the compiler first, but 128-bit addressing would have a maximum addressable RAM of something like 2^70 times all the RAM currently in existence on the planet, so it's moot. (Let's not forget what brings us here, in the first place.)
In terms of type safety, I've realized that everything descending from
QEngineor, equivalently, assuming a state vector representation of a quantum computer simulation should strictly usebitCapIntOclas its masking type, except in public method interfaces. (QUnit, for an alternative example, still strictly usesbitCapInt, for masking.)If my original concern was whether
size_tindexing of arrays would ever exceed 64 bits, the simple and clear answer is "never." The caveat is that we would expect a fully supported set of 128-bit integral types in the compiler first, but 128-bit addressing would have a maximum addressable RAM of something like 2^70 times all the RAM currently in existence on the planet, so it's moot. (Let's not forget what brings us here, in the first place.)