Idiomatic Rust: Don't port C patterns

This is a Rust port of C code, but do not write C in Rust. The goal is correct behavior, not line-by-line translation.

Put logic where the data lives

If a struct has all the information needed to compute something, make it a method:

rust
1// BAD: C-style function with boolean flag soup
2fn text_width(text: &str, charwid: f64, is_mono: bool, font_scale: f64, is_bold: bool) -> f64
3
4// GOOD: The type already knows its properties
5impl PositionedText {
6    fn width_inches(&self, charwid: f64) -> f64 {
7        // self.mono, self.bold, self.big are all right here
8    }
9}

Rationale: Boolean flags are:

• Easy to pass in wrong order (width(s, w, true, 1.0, false) - which bool is which?)
• Require the caller to extract properties just to pass them back in
• Duplicate knowledge that the type already has

Use newtypes for domain concepts

rust
1// BAD: Bare f64 everywhere, easy to mix up inches and pixels
2fn convert(value: f64, scale: f64) -> f64
3
4// GOOD: The type system catches mistakes
5struct Inches(f64);
6struct Pixels(f64);
7fn convert(value: Inches, scale: &Scaler) -> Pixels

Prefer methods over standalone functions

When you find yourself writing foo_bar(bar, ...), consider bar.foo(...) instead. This:

• Groups related functionality
• Enables IDE autocomplete on the type
• Makes the relationship between data and operations explicit

Enums over boolean flags

rust
1// BAD: What does `true` mean here?
2render_text(text, true, false)
3
4// GOOD: Self-documenting
5enum TextAnchor { Start, Middle, End }
6render_text(text, TextAnchor::Start)

The C code is a spec, not a template

When porting C:

1. Understand what the C code does (behavior)
2. Understand why it does it (intent)
3. Implement that behavior idiomatically in Rust

The // cref: comments link to C for reference, but the Rust should stand on its own.