Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I acknowledge that:
cargo test
;cargo fmt
;using
cargo doc
;where appropriate; and
dev
branch.What is the current problem, or feature that should be added?
What aspect of the project needs changing?
The circuit has two public fields that could be altered, resulting in the simulation not working as key assumptions are broken.
There was a mistake in the previous update (0.4.1) where the method
Circuit::get_num_qubits
consumed the circuit, when in fact it should borrow.The quantr errors are public, which may lead to breaking changes in the future. They offer no extra functionality either, other than implementing the std::error::Error trait.
How does this fix and/or better quantr?
If it's a feature, please add examples on how you would use it.
The fields of Circuit have been made private, in addition to all other structs in quantr. Now, the simulation's assumptions can be held up.
The
Circuit::get_num_qubits
method has now been made to borrow the circuit.The quantr errors have been made private, forcing the user to handle them through the trait std::error::Error. This allows for future builds of quantr to differ in their error type.
Is this pull request a major or minor change with respect to the
dev
branch?Please refer to semantic versioning for Rust. If this is a major/breaking change, please add an explanation to why it could not be minor, or equally why it should break the current version.
Major.
What do the unit tests cover?
Description of the unit tests added (if applicable).
Not applicable.
Additional comments.
Any more justifications, examples of output, or even suggestions for improving this pull request template are all welcome!