# \[Guide\] Using sum types to define dynamic C APIs for Julia 1.12 \`--trim\`

**URL:** https://discourse.julialang.org/t/guide-using-sum-types-to-define-dynamic-c-apis-for-julia-1-12-trim/132111
**Category:** General Usage
**Tags:** trim, trimming, static-compilation
**Created:** [September 4, 2025, 10:23pm UTC](https://discourse.julialang.org/t/guide-using-sum-types-to-define-dynamic-c-apis-for-julia-1-12-trim/132111 "2025-09-04T22:23:53Z")
**Posts on this page:** 1
**Showing post:** 20

<div class="post-metadata">

### Author: ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)
#### Post date: [September 7, 2025, 2:23pm UTC](https://discourse.julialang.org/t/guide-using-sum-types-to-define-dynamic-c-apis-for-julia-1-12-trim/132111/20 "2025-09-07T14:23:58Z")

</div>

> [@RomeoV](#):
>
> we want to write a function
> 
> ```julia-auto
> @ccallable function matrixsum_cc(sz::Integer, ptr::Ptr{Cdouble}, mattype::MatType.Enum)::Cdouble
> m = build_matrix(sz, ptr, mattype)
> return sum(m)
> end
> 
> ```
> 
> that is trimmable

> [@RomeoV](#):
>
> ```julia-auto
> @data MyMatrix{T<:Number} begin
> DenseMat(Matrix{T})
> DiagMat(Diagonal{T, Vector{T}}) # <- Make sure this is a concrete type. `Diagonal{T}` wouldn't be enough.
> end
> 
> ```

Does Union-splitting the two possible concrete types for `m` not remove dynamic dispatches? Or is Union-split code not trimmable for another reason?

In general cases though [I agree](https://discourse.julialang.org/t/what-is-the-julia-equivalent-of-rust-option-t/122134/11) with this approach to static code.

> [@juliohm](#):
>
> If we have to rewrite code with wrapper sum-types to achieve static compilation, we are basically reviving the two-language problem.

It’s only the two-language problem if we’re writing essentially the same code in another language. Putting aside the already addressed caveat that there aren’t 2 languages, I would argue that working with sum types, even if wholly internally like this, is semantically different enough from dynamically dispatching over runtime types. We wouldn’t call edits for multithreading or GPU arrays to be a two-language problem for the same reason. As nice as easy `@static_please <expr>` and `@multithread_please <expr>` macros would be, programming isn’t _that_ declarative.

I think the juliac talks did speculate on more aggressive whole-program optimizations that branch over more types in an inferred `Union`. But it wasn’t clear what the limitations there are; I believe I’ve read that Julia is too slow to build if the compiler generally tries to compile 10 possibilities instead of falling back to dynamic dispatch. Sum types on the other hand can be isolated to specified contexts instead, and they at their best would require about the same code as anything handled by a macro or compiler at their best (`sum(variant(m))` is a lot shorter than a trivial match statement repeating an expression, though I’m not sure how `variant` calls are type-stable).

---

_[View the full topic](https://discourse.julialang.org/t/guide-using-sum-types-to-define-dynamic-c-apis-for-julia-1-12-trim/132111)._