As lead developer of Qrack and PyQrack, I have already admitted that there is a real reason to prioritize "memory safety" in a sense comparable to Rust, with which it might not be feasible to achieve exact parity, but at least a specific round of changes should be made to avoid obvious segmentation faults.
In this release, building on previous releases that prevented requesting any qubits outside of the range of allocated qubits in a simulator, it is now also _not_ possible without raising exception to specify the same control or target qubit more than once in the same gate, which would result in undefined behavior. Before this release, it might have been possible to cause OpenCL kernels and CPU equivalents to left-shift for an indefinite number of increments by specifying repeated control qubits, leading to potential out-of-bounds heap access attempts. Instead, the user now receives a `std::invalid_argument` exception before the out-of-bounds access is attempted, (translated to a Python exception, in PyQrack).
(Qrack v8 is planned to continue prioritizing manual memory safeguards like these. However, on an aside, when the statically-linked C++11 Qrack API accepts read-only `complex` type pointers with implicit array length, I suspect this greatly benefits FORTRAN LAPACK interface, as opposed to `std::vector`-based implementations or similar, and so maybe we _should_ compromise for the sake of performance when it is acceptably "safe enough.")
List initializers were also brought up to a better code standard in this release, though no warnings or errors surfaced as a result of the conversion, so this difference is likely more-or-less inconsequential.