Why accept &str in a read-only normalization function?

The caller keeps ownership while the function reads the value.

A teammate wants to hide ownership inside a convenient helper. What should you check first?

Whether the helper makes ownership, inputs, failures, and tests easier to review.

Whether it reduces the number of files regardless of behavior.

Whether it removes the need for the lesson checklist.

Whether it can skip the production signals for this course.

Which artifact best proves this Rust Systems lesson is ready for review?

A repeatable check tied to borrow and cargo test output.

A note that says the happy path was manually clicked once.

A screenshot with no command, test, or failure-mode context.

A broad refactor that avoids the specific lesson outcome.

Basic ownership contracts: a teammate says the happy path works, but "Borrow versus own" is still implicit. What should you ask for before merging?

A small contract, test, or review artifact that proves borrow versus own under a realistic failure case.

Skip compiler, OpenAPI, SQL, or host evidence until the capstone.

Hide the decision inside framework defaults so reviewers have less to read.

Treat production behavior as separate from the lesson implementation.

A reviewer has five minutes to evaluate this basic Rust Systems slice. Which evidence is strongest?

A focused artifact for recoverable result plus a repeatable test, log, OpenAPI diff, or deployment check.

A passing build with no note about contracts, query shape, or operations.

A screenshot of Swagger without checking response or failure cases.

A broad rewrite that does not map to the stage milestone.

Learn / Rust Practical Systems

Ownership, Config, and Results

Use borrowing, owned return values, enums, and Result to build small reliable system components.

Course: Rust Practical Systems. Level: Intermediate. Topic: Systems reliability.

Stage: basic - Basic ownership contracts - Rust ownership, config, and Result contracts. Start by making data ownership, configuration parsing, and recoverable errors explicit.

Outcomes

Borrow read-only inputs.
Return owned normalized values.
Use Result for recoverable configuration errors.

Concepts

ownership
borrow
Result
enum

Concept flow

Show how rust ownership, config, and result contracts moves from trigger to implementation outcome in Rust Systems.

Raw config
Parser
Typed config
Result
Service startup

Session flow

Model ownership (concept, 9 min) — Name the decisions behind ownership before writing code.
- Borrow read-only inputs.
- Explain where ownership belongs in job orchestration service.
Build the vertical slice (walkthrough, 16 min) — Implement the smallest useful slice in src/config.rs.
- Return owned normalized values.
- Connect borrow to a working example.
Verify and harden (exercise, 11 min) — Add tests for invalid config.
- Use Result for recoverable configuration errors.
- Record one risk or follow-up before moving on.

Code example

Rust in src/config.rs.

fn normalize_slug(input: &str) -> String {
          input
              .trim()
              .to_lowercase()
              .split_whitespace()
              .collect::<Vec<_>>()
              .join("-")
      }

Walkthrough examples

Ownership, Config, and Results in a job orchestration service — A team is extending an Axum service with a companion CLI and needs this lesson's pattern to be clear enough for review, testing, and future maintenance.
- File: src/config.rs
- File: tests/ownership-config-and-results.spec
- File: docs/rust-systems/ownership-config-and-results.md
- Start from the provided Rust snippet and make the intent visible in names and boundaries.
- Apply the checklist item "Borrow when only reading" before adding extra behavior.
- Write down how the implementation changes when borrow fails or becomes slow.

Practice

Parse one environment setting into a typed value.
Return Result instead of panicking.
Add tests for invalid config.

Checklist

Borrow when only reading
Own newly created data
Avoid panic for user input
Test malformed values

Quiz prompts

Why accept &str in a read-only normalization function? — Borrowing is the natural choice when a function only needs temporary read access.
A teammate wants to hide ownership inside a convenient helper. What should you check first? — Place ownership at the boundary that keeps job orchestration service behavior explicit, testable, and reviewable.
Which artifact best proves this Rust Systems lesson is ready for review? — Production-ready learning needs evidence: a test, trace, command, screenshot, or log that catches the risk again.
Basic ownership contracts: a teammate says the happy path works, but "Borrow versus own" is still implicit. What should you ask for before merging? — Borrow versus own belongs in the basic stage only when the decision is visible, testable, and tied to a realistic failure mode.
A reviewer has five minutes to evaluate this basic Rust Systems slice. Which evidence is strongest? — Build the basic Rust config layer: borrowed input helpers, typed config parsing, recoverable Result errors, and tests for malformed values.

Flashcards

Basic ownership contracts: what decision does "Borrow versus own" force you to make? Borrow inputs when reading and return owned values when normalizing or storing data. Evidence prompt: Refactor one helper to accept `&str` and return an owned normalized value.
Basic ownership contracts: what decision does "Typed config" force you to make? Parse environment and file input once into validated startup types. Evidence prompt: Parse one config value into a typed struct and reject invalid input with Result.
Basic ownership contracts: what decision does "Recoverable Result" force you to make? Use Result for user, config, and environment failures instead of panics. Evidence prompt: Replace one panic path with a Result and a test for the error case.
In Rust Systems, what should you remember about ownership? ownership matters here because it supports "Borrow read-only inputs.".
In Rust Systems, what should you remember about borrow? borrow matters here because it supports "Return owned normalized values.".
In Rust Systems, what should you remember about Result? Result matters here because it supports "Use Result for recoverable configuration errors.".
In Rust Systems, what should you remember about enum? enum matters here because it supports "Borrow read-only inputs.".

Labs

Ship a ownership, config, and results slice — Extend an Axum service with a companion CLI with a small but reviewable feature that proves the lesson's architecture in code.
- Build the basic Rust config layer: borrowed input helpers, typed config parsing, recoverable Result errors, and tests for malformed values.
- Refactor one helper to accept `&str` and return an owned normalized value.
- Parse one config value into a typed struct and reject invalid input with Result.
- Replace one panic path with a Result and a test for the error case.
- Parse one environment setting into a typed value.
- Return Result instead of panicking.
- The lab demonstrates the basic ownership contracts outcome without skipping earlier contract evidence.
- Each subtopic has a concrete artifact: Borrow versus own, Typed config, Recoverable Result.
- The review notes explain how this level changes ownership, verification, or operational risk.

Challenge

Review-ready ownership, config, and results (Core) — Build the basic Rust config layer: borrowed input helpers, typed config parsing, recoverable Result errors, and tests for malformed values.
- All checklist items are either implemented or documented with a reason.
- The change can be understood from src/config.rs plus one short note.
- The concept diagram names ownership, failure handling, and verification points.
- A teammate could run the verification steps without asking for hidden context.

Canonical lesson URL