[steego]

I think this proposal ultimately introduces more complexity than it solves. By automatically inserting migrations (whether at compile time or via “migration files”), you end up with a form of hidden control flow that’s arguably worse than traditional overloading or type coercion. In normal type coercion, the transformation is explicit and visible in the language syntax, whereas these “migrations” happen magically behind the scenes.

Second, database migrations are notoriously tricky for developers to manage correctly. They often require significant domain knowledge to avoid breaking assumptions further down the line. Applying that paradigm directly to compiler-managed code changes feels like it would amplify the same problems—especially in languages that rely on strong type inference. The slightest mismatch in inferred types could ripple through a large codebase in ways that are far from obvious.

While it’s an interesting idea in theory, I think the “fix your old code with a macro-like script” approach just shifts maintenance costs elsewhere. We’d still be chasing edge cases, except now they’re tucked away behind code-generation layers and elaborate type transformations. It may reduce immediate breakage, but at the expense of clarity and predictable behavior in the long run.

[lolinder]

> In normal type coercion, the transformation is explicit and visible in the language syntax, whereas these “migrations” happen magically behind the scenes.

I was assuming that the migration would actually alter the call site in a way that is reviewable and committable, not implicitly do it every time it's needed at compile time. If that's the idea, it doesn't alter anything behind the scenes, it does so explicitly and visibly one time to change everything to meet the new requirements.

The larger problem I see is that the applications for this would be extremely limited. There's a reason why they used a simple s/a/Some a/ as an illustration—once you get beyond that the migrations will become a pain to write, a pain to validate, and likely to break tons of code in subtle ways. And since most library code changes aren't this simple kind, it's likely that it's not worth the effort of building and maintaining this migration syntax for something with so narrow an application.