A related concept that IMO still aligns with DRY is that you should only avoid seeming code duplication when things are _semantically_ the same. No matter the m

A related concept that IMO still aligns with DRY is that you should only avoid seeming code duplication when things are _semantically_ the same. No matter the mechanism (codegen, generics, macros, inheritance, ...), if you can't give a concept a meaningful [0] name then you usually shouldn't DRY it up with any mechanism. Your example is a technique I also use a lot, but the critical point is that you're choosing to break out functionality which _is_ easy to name. [0a] More generally, I like a concept of "total" functions -- those which have sensible outputs for all their inputs. It's a bit of a tomayto/tomahto situation defining "all their inputs" (e.g., I'm personally okay using a function name like `unsafe_foo` and expecting a person to read the docs, and on the other extreme some people want sensible answers to anything the type system allows you to input), but the desired end-state is that when the project's requirements change you don't muck around with the ABI and implementation of `count_or_maybe_sort_for_these_three_special_customers_or_else_hit_the_db(...)`, or whatever much more generic and very wrong name the method actually has; the individual components are already correct, so you make the changes at the few methods which are actually wrong given the new requirements. [0b] Another way of thinking about it is whether the two things should always change in tandem. For two largely overlapping beaucratic data formats? Maybe; there's a comment somewhere in this chain suggesting that they'll never go out of sync, but I'm a bit paranoid of that sort of thing. For the particular data structures that are currently shared by those formats? Absolutely not; if one diverges then you can build the new structure and link it in. The old structure is still valid in its own right.