DataWeave 2.5 Generics: How Call-Site Type Parameters Caught 3 Production Bugs

I maintained a shared DataWeave utility library across 12 Mule apps for 2 years. Functions like topN , pipe , and safeGet . All untyped. All accepting Any . All silently producing wrong output when called with wrong types. Last quarter I rewrote them with DataWeave 2.5 call-site generics. Three production bugs surfaced on the first compile. TL;DR DataWeave 2.5 adds Java/TypeScript-style call-site type parameters: fun topN<T>(...) The compiler validates T at every call site — type mismatches become compile errors, not runtime surprises Requires Mule 4.5+ — older runtimes throw parse errors on <T> syntax I caught 3 bugs that had been producing wrong output for 4 months The Problem: Untyped Utility Functions My library had functions like this: fun topN(items, n, comp) = (items orderBy -comp($))[0 to (n - 1)] Takes anything. Returns anything. Works on Arrays of Numbers, Strings, Objects. But there's no type checking at the call site. If someone calls topN(arrayOfStrings, 3, (s) -> s) expec