Developer’s Guide

Ready to contribute, great! There are many ways you can improve SmartCore. Here are some ideas for you.

• Improve SmartCore’s documentation.
• Report an issue in GitHub.
• Contribute new or improve existing code.
• Review pull requests.
• You can contribute to this website by completing, improving, and correcting it.
• Propose new functionality.

How to report an issue?

If you found a bug or problem please do not hesitate to report it by opening an issue in GitHub. Opening an issue is a simple matter of describing your problem or your idea and answering all follow-up questions from developer (if any). We only ask you to follow these simple recommendations when you open a new issue:

• Please verify that your issue is not being currently addressed by other issues or pull requests.
• When you are submitting a bug report, please clearly state your problem and demonstrate it with a simple example if you can. Please attach versions of SmartCore, Rust, your operational system to your report.

How to request a new feature?

The best way to request a new feature is by opening an issue in GitHub. When you submit your idea, please keep in mind these recommendations:

• If you are requesting new algorithm, please add references to papers describing this algorithm. If you have a particular implementation in mind, feel free to share references to it as well. If not, we will do our best to find the best implementation available ourselves.
• Please tell us why this feature is important to you.

Contributing code

Writing new code or fixing existing issues is a great way to contribute. In SmartCore all new code is peer-reviewed by core contributors. Before writing new code, please submit an issue describing your problem or feature and give us some time to look at your proposal and suggest changes (if any).

New code should be submitted as a pull request in GitHub. We do not have any preferences as to Forking vs Branching when it comes to submitting your pull request. Please request to merge your change into the development branch.

To make sure your PR is swiftly approved and merged, please make sure new features are covered by unit tests and properly documented. Also, run these checks locally:

1. cargo test --features "ndarray-bindings, datasets, serde" for unit tests (the nalgebra-bindings feature was removed in 0.3.0 and no longer exists).
2. cargo fmt --all -- --check to verify the code matches the style guidelines.
3. cargo clippy --all-features -- -Drust-2018-idioms -Drust-2024-compatibility -Dwarnings for code linting. As of 0.6, SmartCore targets edition 2024 (MSRV 1.85), so the rust-2024-compatibility lint group is enforced alongside the existing rust-2018-idioms group.
4. cargo +1.85.0 build --all-features to verify the MSRV.

Edition 2024 invariants

The crate was ported from edition 2021 to 2024. When touching library code, keep these invariants intact so the edition-2024 lint group stays clean:

• No return-position impl Trait (RPIT). The codebase returns zero -> impl Trait items today; gate any new RPIT with an explicit lifetime bound and re-run clippy before landing.
• dyn Trait bounds carry explicit lifetimes. All Box<dyn Trait> returns are written as Box<dyn Trait + 'a>. Do not drop the + 'a.
• Tail-expression drop order matters. Edition 2024 reorders temporaries in tail position. When a tail expression owns a temporary that a borrow extends through, bind the owned intermediate to a local first.
• Lint suppressions use #[expect(...)] where the lint actually fires, #[allow(...)] otherwise. #[expect] errors if its lint later stops firing — prefer it for new suppressions where you’ve verified the lint fires.
• No unsafe in library code. Any new unsafe requires clear justification and must not trigger unsafe_op_in_unsafe_fn or other unsafe-attr lints.
• Preserve the bespoke numerical-system logic and performance. The numeric/linalg traits and their concrete impls are hand-tuned; change only the structural form, never the math, indexing scheme, traversal order, or allocation strategy. Verify a refactor is behavior-preserving by re-running cargo test --all-features.

Changes to documentation

If you found a problem in documentation please do not hesitate to correct it and submit your proposed change as a pull request (PR) in GitHub. At this moment documentation is found in several places: API, website and examples. Please submit your pull request to a corresponding repository. If your change is a minor correction (e.g. misspelling or grammar error) there is no need to open a separate issue describing what you’ve found, just correct it and submit your PR!

Another way to make a change in documentation is to open an issue in GitHub.