|
| 1 | +# CLAUDE.md |
| 2 | + |
| 3 | +This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository. |
| 4 | + |
| 5 | +## Build and Test Commands |
| 6 | + |
| 7 | +This is a Swift Package Manager project. Use these commands for development: |
| 8 | + |
| 9 | +```bash |
| 10 | +# Building |
| 11 | +swift build # Build in debug mode |
| 12 | +swift build -c release # Build in release mode |
| 13 | +swift build -v # Build with verbose output |
| 14 | + |
| 15 | +# Testing |
| 16 | +swift test # Run all tests |
| 17 | +swift test -v # Run tests with verbose output |
| 18 | +swift test --filter TestName # Run specific test |
| 19 | +swift test --parallel # Run tests in parallel |
| 20 | + |
| 21 | +# Package Management |
| 22 | +swift package clean # Clean build artifacts |
| 23 | +swift package reset # Reset complete cache/build directory |
| 24 | +swift package update # Update dependencies (note: this project has no dependencies) |
| 25 | +``` |
| 26 | + |
| 27 | +## Architecture Overview |
| 28 | + |
| 29 | +HDXLSIMDSupport provides generic Swift wrappers for Apple's non-generic SIMD matrix and quaternion types. Understanding the three-layer architecture is crucial: |
| 30 | + |
| 31 | +### Three-Layer Type System |
| 32 | +1. **Generic Wrapper** (e.g., `Matrix4x4<Scalar>`) - User-facing generic types |
| 33 | +2. **Storage Type** (e.g., `FloatMatrix4x4Storage`) - Adds Hashable/Codable to native types |
| 34 | +3. **Native SIMD** (e.g., `simd_float4x4`) - Apple's C-based SIMD types |
| 35 | + |
| 36 | +### Key Design Patterns |
| 37 | + |
| 38 | +**Passthrough Protocol**: Central to the architecture, eliminates forwarding boilerplate: |
| 39 | +- Storage types and generic wrappers both conform to `Passthrough` |
| 40 | +- Extensions on `Passthrough` implement forwarding logic once |
| 41 | +- Used extensively throughout matrix and quaternion implementations |
| 42 | + |
| 43 | +**Flat Protocol Hierarchy**: Deliberately avoids deep protocol hierarchies due to Swift compiler limitations: |
| 44 | +- Base protocols: `MatrixProtocol`, `QuaternionProtocol` |
| 45 | +- Size-specific: `Matrix2x2Protocol`, `Matrix3x3Protocol`, etc. |
| 46 | +- Separate operator protocols to avoid ambiguity |
| 47 | + |
| 48 | +**Type Compatibility**: `ExtendedSIMDScalar` links all storage types for a given scalar: |
| 49 | +- Ensures `Matrix2x2<Float>` can multiply with `Matrix2x3<Float>` |
| 50 | +- Manual type-linking simulates higher-kinded types |
| 51 | + |
| 52 | +### Important Implementation Notes |
| 53 | + |
| 54 | +- Heavy use of `@inlinable` for zero-cost abstractions |
| 55 | +- Method pairs: `operation()` returns new value, `formOperation()` mutates in place |
| 56 | +- Consistent naming: `multiplied(by:)`, `divided(by:)`, `adding(_:)` |
| 57 | +- Liberal use of preconditions for runtime safety |
| 58 | +- All types target Swift 6 with full Sendable compliance |
| 59 | + |
| 60 | +### Working with the Codebase |
| 61 | + |
| 62 | +When adding functionality: |
| 63 | +1. Start with the appropriate protocol |
| 64 | +2. Implement in a `Passthrough` extension if possible |
| 65 | +3. Only add to concrete types if necessary |
| 66 | + |
| 67 | +When modifying existing code: |
| 68 | +- Maintain the three-layer architecture |
| 69 | +- Follow existing naming conventions |
| 70 | +- Ensure Sendable compliance is maintained |
| 71 | +- Add comprehensive tests for new functionality |
| 72 | + |
| 73 | +### Future Direction |
| 74 | + |
| 75 | +The project is planning a migration to macro-based code generation to: |
| 76 | +- Reduce protocol complexity and compilation times |
| 77 | +- Eliminate copy-paste boilerplate |
| 78 | +- Co-generate implementation and tests |
| 79 | + |
| 80 | +Until then, maintain the current protocol-based architecture. |
0 commit comments