Description
While looking through the crate's public API, I noticed a few inconsistencies that suggest there's no referenced style-guide baseline behind naming/type-shape decisions:
- Some plain accessors use a
get_ prefix while neighboring accessors in the same files don't, which reads as inconsistent with the Rust API Guidelines' C-GETTER convention.
- Identifier fields (session/task/tool-use/client id) are represented as bare
String/Arc<str> rather than distinct types, so nothing stops one id kind being passed where another is expected.
No repo doc references a style guide, so it's unclear whether this is intentional or just drift. Simplest fix: state explicitly in contributor docs that code should be idiomatic and follow the official Rust API Guidelines (https://rust-lang.github.io/api-guidelines/) - its naming (C-*) and type-safety (C-NEWTYPE) checklists already cover both examples above, so this is a documentation change, not a new process to design. Bringing existing API (like the two examples above) in line with the referenced guide is a separate, breaking-change follow-up - worth tracking on its own once the guide itself is adopted, not part of this issue.
Reproduction Steps
rg -n "pub fn get_[a-z_]+\(" crates/rmcp/src - 8 matches, all plain field/derived-value accessors inconsistent with sibling accessors in the same files.- Compare
SessionId/EventId/StreamId/task_id/tool_use_id/client_id field types across model.rs, task_manager.rs, transport/auth.rs - all bare String/Arc<str>/type aliases, no newtype.
- Checked CONTRIBUTING.md and the repo for any reference to language-specific style guide - none found. CONTRIBUTING.md only says "follow existing code style" / "follow the repository's established patterns," with no concrete convention to check against.
Expected Behavior
Contributor docs cite an explicit style-guide baseline for public API naming/shape.
Actual Behavior
No such reference exists, so it's unclear whether naming inconsistencies like the above are intentional.
Logs / Evidence
Description
While looking through the crate's public API, I noticed a few inconsistencies that suggest there's no referenced style-guide baseline behind naming/type-shape decisions:
get_prefix while neighboring accessors in the same files don't, which reads as inconsistent with the Rust API Guidelines' C-GETTER convention.String/Arc<str>rather than distinct types, so nothing stops one id kind being passed where another is expected.No repo doc references a style guide, so it's unclear whether this is intentional or just drift. Simplest fix: state explicitly in contributor docs that code should be idiomatic and follow the official Rust API Guidelines (https://rust-lang.github.io/api-guidelines/) - its naming (
C-*) and type-safety (C-NEWTYPE) checklists already cover both examples above, so this is a documentation change, not a new process to design. Bringing existing API (like the two examples above) in line with the referenced guide is a separate, breaking-change follow-up - worth tracking on its own once the guide itself is adopted, not part of this issue.Reproduction Steps
rg -n "pub fn get_[a-z_]+\(" crates/rmcp/src- 8 matches, all plain field/derived-value accessors inconsistent with sibling accessors in the same files.SessionId/EventId/StreamId/task_id/tool_use_id/client_idfield types acrossmodel.rs,task_manager.rs,transport/auth.rs- all bareString/Arc<str>/type aliases, no newtype.Expected Behavior
Contributor docs cite an explicit style-guide baseline for public API naming/shape.
Actual Behavior
No such reference exists, so it's unclear whether naming inconsistencies like the above are intentional.
Logs / Evidence