Rust Macros: Zero-Cost Abstraction for Type Specialization

---

# 🦀 Rust Macros: Zero-Cost Abstraction 🧩

## Why Wasn't This Done Before? — A Case Study in Tech Debt

@luk036 👨‍💻 · 2026 📅

---

### 📋 Agenda

**Part 1: Macro Design Patterns** 🏗️
- Why Macros for Type Specialization
- Variadic Shift Chains
- Core Algorithm Macros

**Part 2: Case Study — rat-trig-rs** 📐
- Signed vs Unsigned Algorithm Families
- Helper Function Delegation

**Part 3: Reverse Conversion** 🔄
- `impl_to_decimal_i!`
- `impl_to_decimal_i_result!`

]

**Part 4: Macro Pitfalls** ⚠️
- The `const fn` Bug — Root Cause Analysis
- Silent Truncation
- Trapped in `mod tests`

**Part 5: Testing & Lessons** 🎯
- 170+ Tests All Pass
- Key Takeaways
- Macro Best Practices

]

---

## 🏗️ Macro Design Patterns

---

### Why Macros for Type Specialization? 🤔

The CSD library needed **the same algorithm** for 3 integer widths (32/64/128 bit):

```rust
// Before: hand-written for each type
pub fn to_csd_i(decimal_value: i32) -> String { ... }     // i32

// Trapped in test module (not exported):
pub fn to_csd_i64(decimal_value: i64) -> String { ... }   // i64
pub fn to_csd_i128(decimal_value: i128) -> String { ... }  // i128
```

**The Problems:**
- ❌ Same algorithm **copied 3×** — any bug fix needs 3 edits
- ❌ `to_csd_i128` used a **manual loop** instead of the shared `highest_power_of_two_in`
- ❌ i64/i128 variants were **trapped in a test module** (never exported)
- ❌ **No zero-guard** for i64/i128 variants

**Solution:** `macro_rules!` — one definition, N instantiations.

---

### Why Macros and Not Generics? 🤔

Could we use **generic functions** instead? Partially.

| Macro | Can generic replace? | Works on stable? |
|-------|:-------------------:|:----------------:|
| `impl_to_decimal_i!` | ✅ Trait + generic fn | ✅ |
| `impl_to_decimal_i_result!` | ✅ Trait + generic fn | ✅ |
| `impl_to_csd_i!` | ✅ Trait + assoc type | ✅ (same effort) |
| `impl_to_csdnnz_i!` | ✅ Trait + assoc type | ✅ (same effort) |
| `impl_highest_power_of_two_in!` | ❌ Const generics | ❌ **Nightly only** |

---

**The dealbreaker — variadic shift chain:**

```rust
// Each width needs a different number of shifts:
// u32:  5 shifts  (1, 2, 4, 8, 16)
// u64:  6 shifts  (... , 32)
// u128: 7 shifts  (... , 64)

fn hp2_generic<const N: usize>(x: u64) -> u64 {
    // Can't unroll variable-length shift chain on stable!
    // Needs generic_const_exprs (nightly-only)
}
```

**So macros win because:**
- 🎯 Variadic shifts **force** macros or nightly generics
- 🪶 20 lines of macro vs ~40 lines of trait boilerplate
- ⚡ Same compiler output — zero overhead either way
- 😄 **The laziest thing that works** — beats writing it 3× by hand

---

### Macro Anatomy 📐

.mermaid[
<pre>
graph LR
    Def["macro_rules! mcr_name {\n  ($param:t, $fn:ident) => {\n    pub fn $fn(x: $param) { ... }\n  };\n}"] --> Call1["macro_name!(i32, my_fn_i32)\n→ pub fn my_fn_i32(x: i32)"]
    Def --> Call2["macro_name!(i64, my_fn_i64)\n→ pub fn my_fn_i64(x: i64)"]
    Def --> Call3["macro_name!(f64, my_fn_f64)\n→ pub fn my_fn_f64(x: f64)"]

style Def fill:#ff9800,stroke:#e65100,stroke-width:3px
    style Call1 fill:#e3f2fd
    style Call2 fill:#bbdefb
    style Call3 fill:#90caf9
</pre>
]

---

**Key parameters used in CSD macros:**

| Fragment Type | Example | Purpose |
|:--------------|:--------|:--------|
| `$fn_name:ident` | `to_csd_i64` | Function name to generate |
| `$ty:ty` | `i64` | Integer type to specialize on |
| `$uint:ty` | `u64` | Unsigned counterpart |
| `$hp2_fn:ident` | `highest_power_of_two_in_u64` | Helper function name |

---

### Macro 1: Variadic Shift Chain 🏔️

`impl_highest_power_of_two_in!` — finds the highest power of two ≤ input:

```rust
macro_rules! impl_highest_power_of_two_in {
    ($fn_name:ident, $ty:ty, $($sn:expr),+) => {
        pub fn $fn_name(x: $ty) -> $ty {
            let mut x = x;
            $(x = x | (x >> $sn);)+  // ← repeat for each shift amount
            x - (x >> 1)
        }
    };
}
```

**Instantiations:**

.mermaid[
<pre>
graph TD
    M["impl_highest_power_of_two_in!"] --> U32["highest_power_of_two_in\nu32, shifts=(1,2,4,8,16)"]
    M --> U64["highest_power_of_two_in_u64\nu64, shifts=(…,32)"]
    M --> U128["highest_power_of_two_in_u128\nu128, shifts=(…,64)"]

style M fill:#ff9800,stroke:#e65100,stroke-width:3px
    style U32 fill:#e3f2fd
    style U64 fill:#bbdefb
    style U128 fill:#90caf9
</pre>
]

> 💡 The **variadic `$($sn:expr),+`** pattern handles different shift chain lengths: 5 shifts for u32, 6 for u64, 7 for u128.

---

### Macro 2: Core Algorithm Template 🔄

`impl_to_csd_i!` — the full CSD integer conversion algorithm:

```rust
macro_rules! impl_to_csd_i {
    ($fn_name:ident, $sint:ty, $uint:ty, $hp2_fn:ident) => {
        #[doc = concat!("Convert a `", stringify!($sint),
               "` integer to CSD.")]
        #[must_use]
        pub fn $fn_name(decimal_value: $sint) -> String {
            if decimal_value == 0 {
                return "0".to_string();  // ← zero guard!
            }
            let utemp = if decimal_value < 0 {
                (decimal_value as $uint).wrapping_neg()
            } else {
                decimal_value as $uint
            };
            let temp = utemp * 3 / 2;
            let mut p2n = $hp2_fn(temp) as $sint * 2;
            // ... algorithm body same for all widths
        }
    };
}
```

---

### Macro 3: With Extra Constraint ✂️

`impl_to_csdnnz_i!` — same algorithm + non-zero digit limit:

.font-sm[
```rust
macro_rules! impl_to_csdnnz_i {
    ($fn_name:ident, $sint:ty, $uint:ty, $hp2_fn:ident) => {
        pub fn $fn_name(decimal_value: $sint,
                        max_non_zeros: u32) -> String {
            if decimal_value == 0 {
                return "0".to_string();
            }
            let utemp = if decimal_value < 0 {
                (decimal_value as $uint).wrapping_neg()
            } else {
                decimal_value as $uint
            };
            let temp = utemp * 3 / 2;
            let mut p2n = $hp2_fn(temp) as $sint * 2;
            let mut csd = Vec::new();
            let mut count = 0u32;
            // ... same algorithm but counts non-zeros
        }
    };
}
```
]

**This macro discovered a bug:** `to_csd_i128` was using a manual bit-counting loop instead of `highest_power_of_two_in_u128`! 🐛

---

### Before vs After: CSD Library 📊

**Before** (per type):
```text
src/csd.rs
├── highest_power_of_two_in(i32)       ← hand-written
├── to_csd_i(i32)                      ← public
├── [test module]  ← ⚠️
│   ├── to_csd_i64(i64)                ← trapped! exact same code
│   ├── to_csd_i128(i128)              ← trapped! manual loop
│   ├── to_csdnnz_i64(i64)             ← trapped!
│   └── to_csdnnz_i128(i128)           ← trapped!
```

**After** (from macros):
```text
src/csd.rs
├── impl_highest_power_of_two_in!       ← 1 macro → 3 functions
├── impl_to_csd_i!                      ← 1 macro → 3 pub functions
├── impl_to_csdnnz_i!                   ← 1 macro → 3 pub functions
├── [test module]                       ← clean: no duplicate code!
```

> **3 macros replaced 10 hand-written functions.** 🎯

---

## 📐 Case Study: rat-trig-rs

### Same Problem, Pure Arithmetic Domain

---

### The Duplication: 24 Hand-Written Functions

The `rat-trig-rs` library needed `const fn` variants of 4 algorithms for **6 integer types** (i32, i64, i128, u32, u64, u128):

```text
Before (const_trigonom.rs, 267 lines of duplication):
├── quadrance_i64 / _i32 / _i128 / _u32 / _u64 / _u128    ← 6× identical body
├── archimedes_i64 / _i32 / _i128 / _u32 / _u64 / _u128    ← 6× identical body
├── spread_i64 / _i32 / _i128 / _u32 / _u64 / _u128        ← 6× identical body
├── cross_i64 / _i32 / _i128 / _u32 / _u64 / _u128         ← 6× identical body
```

**After** (from macros, 106 lines):
```text
├── impl_quadrance_signed! / impl_quadrance_unsigned!       ← 2 macros → 6 fns
├── impl_archimedes!                                        ← 1 macro → 6 fns
├── impl_spread!                                             ← 1 macro → 6 fns
├── impl_cross_signed! / impl_cross_unsigned!               ← 2 macros → 6 fns
```

> **6 macros replaced 24 hand-written functions. 161 lines net reduction (267 − 106).**

---

### Signed vs Unsigned: Different Subtraction Semantics 🔀

**Quadrance** differs between signed and unsigned types:

```rust
// Signed integer: direct subtraction (can be negative, squaring fixes it)
macro_rules! impl_quadrance_signed {
    ($ty:ident, $name:ident) => {
        pub const fn $name(p_1: ($ty, $ty), p_2: ($ty, $ty)) -> $ty {
            let dx = p_1.0 - p_2.0;          // may be negative
            dx * dx + dy * dy                 // squaring handles sign
        }
    };
}

// Unsigned integer: abs_diff (subtraction not possible)
macro_rules! impl_quadrance_unsigned {
    ($ty:ident, $name:ident) => {
        pub const fn $name(p_1: ($ty, $ty), p_2: ($ty, $ty)) -> $ty {
            let dx = p_1.0.abs_diff(p_2.0);  // safe for unsigned
            dx * dx + dy * dy
        }
    };
}
```

**Cross** has the same signed/unsigned split: direct subtraction vs `abs_diff`.

---

### Helper Function Delegation

`impl_spread!` — the formula is type-agnostic, but each type needs its matching quadrance:

```rust
macro_rules! impl_spread {
    ($ty:ident, $name:ident, $quad_fn:ident) => {
        pub const fn $name(v_1: ($ty, $ty), v_2: ($ty, $ty)) -> $ty {
            let dot_product = v_1.0 * v_2.0 + v_1.1 * v_2.1;
            let q_1 = $quad_fn(v_1, (0, 0));  // ← delegates to matching quad
            let q_2 = $quad_fn(v_2, (0, 0));
            let q_product = q_1 * q_2;
            if q_product == 0 { 0 }
            else { q_product - dot_product * dot_product / q_product }
        }
    };
}

// Each spread pairs with its type-specific quadrance:
impl_spread!(i32, spread_i32, quadrance_i32);
impl_spread!(u64, spread_u64, quadrance_u64);
```

`impl_archimedes!` needs **no delegation** — same formula for all 6 types.

---

### Why `pub const fn` Works Here but Not in CSD

**Both libraries use the same macro pattern — but CSD's `pub const fn` symbols vanished from .rlib, while rat-trig-rs's work perfectly.**

The difference lies in what the generated function body does:

```rust
// ─── CSD: const fn that CAN'T work ───
pub const fn to_decimal_i64(csd: &str) -> i64 {
    let bytes = csd.as_bytes();   // &str → &[u8] (const-stable)
    while i < bytes.len() {       // while loop (const-stable since 1.46)
        match bytes[i] {          // match on bytes (const-stable)
            b'-' => { /* ... */ }
            _ => panic!("...")    // ← panic!() in const fn
        }
    }
}

// ─── rat-trig-rs: const fn that WORKS ───
pub const fn quadrance_i32(p1: (i32,i32), p2: (i32,i32)) -> i32 {
    let dx = p1.0 - p2.0;         // integer arithmetic
    let dy = p1.1 - p2.1;         // (const-stable since Rust 1.0)
    dx * dx + dy * dy
}
```

---

### Root Cause: The `panic!()` Barrier

`panic!()` in `const fn` was **not stabilized until Rust 1.57 (October 2021).**

| Capability | Stabilized in | CSD function uses? |
|------------|:------------:|:------------------:|
| `+`, `-`, `*`, `/` on integers | Rust 1.0 ✅ | ✅ |
| `if`, `while`, `match` | Rust 1.46 ✅ | ✅ |
| `&str::as_bytes()` | Rust 1.39 ✅ | ✅ |
| **`panic!()` in const fn** | **Rust 1.57** ⚠️ | ✅ **← barrier** |
| `String` allocation | **Unstable** ❌ | ❌ (not in to_decimal_i) |

---

But even on Rust 1.57+, `panic!()` in const fn has a subtle problem:

> **A `const fn` containing `panic!()` can only be evaluated at compile time when the panicking path is provably unreachable.** If the compiler cannot prove the panic won't fire (because it depends on runtime data like a `&str` input), the function body is still valid const fn — but the interaction with `macro_rules!` symbol emission can fail.

**The compiler sees:**
- CSD macro: `pub const fn` with `panic!()` + string deref → **drops the symbol** (conservative)
- rat-trig macro: `pub const fn` + pure integer ops → **emits the symbol** (trivially safe)

---

### Verification: It's the `panic!()`, Not the Macro

To confirm the theory, consider the hand-written variant that DID work:

```rust
// Hand-written, directly in source file: worked ✅
pub const fn to_decimal_i(csd: &str) -> i32 { ... panic!(...) ... }
```

```rust
// Same body, generated by macro: failed ❌
// Symbols vanished from .rlib, doc-tests failed
macro_rules! impl_to_decimal_i {
    ($fn_name:ident, $ty:ty) => {
        pub const fn $fn_name(csd: &str) -> $ty { ... panic!(...) ... }
    };
}
```

**Hypothesis:** When the Rust compiler processes a macro expansion containing `pub const fn` + `panic!()` + non-trivial const evaluation (string iteration), it takes a conservative path — verifying the const fn validity involves evaluating the macro-expanded body, which triggers a `panic!()`-related code path that silently fails to register the symbol for external linkage.

---

**The fix is trivial:** `pub fn` instead of `pub const fn`. No loss of functionality (these functions are rarely called in const contexts anyway), and the symbols are properly emitted.

> 💡 **Lesson for macro authors:** If your macro generates `pub const fn` with complex bodies (especially `panic!()`, string ops, or heap types), verify with `cargo test --doc` and `nm` on the .rlib. If symbols vanish, use `pub fn`.

---

## 🔄 Reverse Conversion

---

### Macro 4: Reverse Direction 🏗️

`impl_to_decimal_i!` — CSD string → integer (same `macro_rules!` pattern):

```rust
macro_rules! impl_to_decimal_i {
    ($fn_name:ident, $ty:ty) => {
        #[doc = concat!("Convert a CSD string to `", stringify!($ty), "`.")]
        pub fn $fn_name(csd: &str) -> $ty {
            let mut result: $ty = 0;
            let bytes = csd.as_bytes();
            let mut i = 0;
            while i < bytes.len() {
                match bytes[i] {
                    b'0' => result = result << 1,
                    b'+' => result = (result << 1) + 1,
                    b'-' => result = (result << 1) - 1,
                    _ => panic!("Work with 0, +, and - only"),
                }
                i += 1;
            }
            result
        }
    };
}
```

> Same algorithm, 3 types — the macro pattern scales to 6 function families.

---

### Macro 5: Result-Wrapper Variant 📦

`impl_to_decimal_i_result!` — delegates type-specific parsing to inner function:

```rust
macro_rules! impl_to_decimal_i_result {
    ($fn_name:ident, $ty:ty, $inner_fn:ident) => {
        pub fn $fn_name(csd: &str) -> CsdResult<$ty> {
            // Validate characters (same for all types)
            let bytes = csd.as_bytes();
            for &c in bytes {
                if !matches!(c, b'+' | b'-' | b'0') {
                    return Err(CsdError::InvalidCharacter(c as char, 0));
                }
            }
            // Delegate to type-specific parser
            Ok($inner_fn(csd))
        }
    };
}
```

**Key insight:** The `$inner_fn:ident` parameter lets the **validation logic** live in one macro while calling out to type-specific implementations.

---

## ⚠️ Macro Pitfalls

---

### Pitfall 1: `pub const fn` + Macro = Fragile

**The symptom:** `pub const fn` generated by a macro **disappeared from compiled output** — but only for certain function bodies.

**CSD library: string + panic!() → ❌ symbol vanishes**

```rust
macro_rules! impl_to_decimal_i {
    ($fn_name:ident, $ty:ty) => {
        pub const fn $fn_name(csd: &str) -> $ty {
            // ... match on bytes ...
            // ... panic!("...") ...
            //   ^^^^^ vanished from .rlib
        }
    };
}
```

]
.pull-right[

**rat-trig-rs: pure arithmetic → ✅ symbol emitted**

```rust
macro_rules! impl_quadrance_signed {
    ($ty:ident, $name:ident) => {
        pub const fn $name(p1, p2) -> $ty {
            p1.0 - p2.0   // arithmetic only
            // ✅ present in .rlib
        }
    };
}
```

]

---

| Library | Body Contains | `pub const fn` ? |
|---------|:-------------|:----------------:|
| CSD | `panic!()`, `&str`, `match` bytes | ❌ vanishes |
| rat-trig | integer `+ - * /` only | ✅ works |

**Why?** The `panic!()` macro in const fn was stabilized only in Rust 1.57. Even after stabilization, macro-expanded `const fn` containing `panic!()` + non-trivial evaluation (string iteration) can cause the compiler to **fail to register the external symbol** — it verifies the const body, encounters the `panic!()` edge case, and silently drops the linkage.

**The `&str` input also matters:** A const fn that takes `&str` and calls `as_bytes()` + `panic!()` requires the compiler to reason about whether the panic can fire at compile time — a conservative check that can fail in macro expansions.

**Fix:** Use `pub fn` when the generated body contains `panic!()`, `&str` parameters, or heap types. Use `pub const fn` freely for pure arithmetic.

---

### Pitfall 2: Silent Truncation 🐛

The old hand-written `_result` variants had a **truncation bug** exposed by the macro refactoring:

```rust
// ❌ Before: truncates through i32 silently
pub fn to_decimal_i64_result(csd: &str) -> CsdResult<i64> {
    // ... validation ...
    Ok(to_decimal_i(csd) as i64)  // ← i32::MAX = 2.1B, i64::MAX = 9.2E18
}

// ✅ After: calls type-specific parser
pub fn to_decimal_i64_result(csd: &str) -> CsdResult<i64> {
    // ... validation ...
    Ok(to_decimal_i64(csd))  // ← full i64 precision!
}
```

The **macro prevented this bug** because each generated function calls the correct type-specific inner function via `$inner_fn:ident`.

> 🎯 **Macros don't just reduce duplication — they eliminate whole classes of bugs.**

---

### Pitfall 3: Trapped in `mod tests` 🚪

Before the refactoring, `to_csd_i64` and `to_csd_i128` lived in `mod tests`:

```rust
mod tests {
    // These looked public, but were only visible within tests
    pub fn to_csd_i64(decimal_value: i64) -> String { ... }
    pub fn to_csd_i128(decimal_value: i128) -> String { ... }
}
```

**The trap:**
- ✅ Unit tests could use them → **false confidence**
- ❌ External code could **never** call them
- ❌ `cargo doc` didn't show them
- ❌ Doc-tests failed (compiled as external crate)

> **If a function should be public, make it public at the module level — not inside `mod tests`.**

---

## 🧪 Testing & Lessons

---

### 🧪 All Tests Pass: 170+ ✅

.mermaid[
<pre>
graph TD
    CSD_Unit["CSD Unit\n88 ✅"] --> All["All Pass\n🎉"]
    CSD_Main["CSD CLI\n22 ✅"] --> All
    CSD_Integ["CSD Integration\n25 ✅"] --> All
    CSD_Prop["CSD Property\n4 ✅"] --> All
    CSD_Doc["CSD Doc-Tests\n21 ✅"] --> All
    RT_Unit["rat-trig Unit\n149 ✅"] --> All
    RT_Integ["rat-trig Integ\n10 ✅"] --> All
    RT_Doc["rat-trig Doc\n14 ✅"] --> All
    Cpp["C++ Tests\n74 ✅"] --> All

style CSD_Unit fill:#4caf50,color:#fff
    style CSD_Main fill:#66bb6a,color:#fff
    style CSD_Integ fill:#81c784,color:#fff
    style CSD_Prop fill:#a5d6a7,color:#fff
    style CSD_Doc fill:#c8e6c9,color:#fff
    style RT_Unit fill:#90caf9,color:#fff
    style RT_Integ fill:#bbdefb,color:#fff
    style RT_Doc fill:#e3f2fd,color:#fff
    style Cpp fill:#ffcc80,color:#fff
    style All fill:#ff9800,stroke:#e65100,stroke-width:3px
</pre>
]

```
CSD:    139 tests + 21 doc-tests = 160 ✅
rat-trig: 149 tests + 10 integ + 14 doc-tests = 173 ✅
C++:    74 tests + 233 assertions                            ✅
```

---

### Key Takeaways 🎯

.pull-left[
.mermaid[
<pre>
graph TD
    M["Declarative Macros\nmacro_rules!"] --> D["DRY Code\nOne algorithm, N types"]
    M --> C["Compile-time\nZero runtime cost"]
    M --> E["Exported\nAll variants public"]

D --> T["170+ tests\nall pass ✅"]
    C --> I["Inline-expanded\nby compiler 📦"]
    E --> B["Bug found:\ntruncation in\n_result variants 🐛"]

style M fill:#ff9800,stroke:#e65100,stroke-width:3px
    style D fill:#e3f2fd
    style C fill:#e3f2fd
    style E fill:#e3f2fd
    style T fill:#4caf50,color:#fff
    style I fill:#2196f3,color:#fff
    style B fill:#f44336,color:#fff
</pre>
]
]
.pull-right[
1. **Macros eliminate duplication** — 9 macros replaced 34 hand-written functions across 2 libraries
2. **`pub const fn` inside macros: works for pure arithmetic, fragile for `panic!()` + string ops** — always verify with `cargo test --doc` and `nm`
3. **Test-module code creates false confidence** — if it should be public, make it so
4. **`as` casts truncate silently** — macros prevent this by dispatching to correct types
5. **Zero overhead** — macros expand at compile time, identical to hand-written code
]

---

### Macro Best Practices 📋

.pull-left[
**✅ Do:**
- Use macros when the **same algorithm** applies to multiple types
- Pass helper function names as `$fn:ident` parameters for composability
- Split signed/unsigned macros when subtraction semantics differ
- Verify `pub const fn` in macros with `cargo test --doc` + `nm` on .rlib
]
.pull-right[
**❌ Don't:**
- Use `pub const fn` in macros with `panic!()`, string ops, or heap types — use `pub fn`
- Hide generated functions in `mod tests`
- Use `as` casts between width-varying types
- Assume macro-generated items behave identically to hand-written ones
]

**🔍 Verify with:**
```bash
cargo test --doc           # doc-tests = external crate view
nm target/debug/*.rlib     # check symbols in compiled output
cargo doc --no-deps        # verify documentation generation
```

---

### Why Wasn't This Done Before? 🤷

The macro refactoring took ~20 minutes per library. So why did the duplication exist for so long?

.mermaid[
<pre>
graph TD
    Start["Original Rust Code\nhad duplication"] --> R1["🧱 Cargo-cult:\n'C++ uses templates,\nport 1:1 to fn'"]
    Start --> R2["👀 Nobody reviewed\n`mod tests`:\n'they compile, they pass'"]
    Start --> R3["📈 Incremental dev\nwithout cleanup:\n'add i64 quick, fix later'"]
    Start --> R4["🤖 AI didn't flag it:\n'following existing\npattern blindly'"]

R1 --> Result["❌ 10 + 24 hand-written fns\ninstead of 3 + 6 macros"]
    R2 --> Result
    R3 --> Result
    R4 --> Result

style Start fill:#ff9800,stroke:#e65100
    style R1 fill:#e3f2fd
    style R2 fill:#e3f2fd
    style R3 fill:#e3f2fd
    style R4 fill:#e3f2fd
    style Result fill:#f44336,color:#fff
</pre>
]

---

**The four forces that created the duplication:**
1. **Cargo-cult from C++** — templates → concrete fns, missing Rust's `macro_rules!`
2. **Test-module blind spot** — `pub fn` inside `mod tests` looks public, isn't
3. **Incremental rot** — "just add i64 real quick" → permanent fixture
4. **AI pattern-matching** — followed existing style instead of questioning it

> 💡 **Lesson:** The same forces that create tech debt also make AI amplify it. Always ask: *"Is there an idiomatic way to do this in **this** language?"* not *"How was it done before?"*

---

# 🙋 Q&A

**Rust Macros: Zero-Cost Abstraction for Type Specialization**

*What questions do you have?* 🎤

---

# 👋 Thank You!

## Write Code Once, Use Everywhere with Macros! 🦀 🧩 🚀