The intent was not to stop conversation but rather clarify that both the ComptimeMap reduction and the original were problematic. Rather, knowing the issues opens up exploring the possibility of solving them.
There are other ways to handle errors that can be explored but as of yet there hasn’t been a good language native way to handle it in any language that I’ve seen.
Haskell Either/Maybe encourages handling failure further out or not until the edge, rust makes it verbose with the same pattern, go allocates and performs needless work to make the slow path a really slow one, erlang restarts bad nodes and may report if the supervisor is configured to do so, C just doesn’t do anything, mercury backtracks / fails the goal with cc unless you succeed to return a context, and exceptions are a mix of allocation/generating bad code. There are more I haven’t listed but none of the languages I’ve seen handle errors well when you need diagnostics. It’s only ever been applications that have included them in their design that have.
All of this (based on my exploration) hints towards that a language feature for diagnostics is not going to cover enough cases and may even harm say embedded. Thus I don’t think there is a decent solution other than designing your application to account for errors.
Note that errors are not uncommon thus handling them with the same importance as other data being transformed is likely going to yield much better design than trying to work around a common case. “Hacks”, “workarounds”, etc is a hint that errors were not considered as part of the design and instead treated as exceptional cases that likely never occur thus resulting in friction.