4 ms·

Currently the compiler can choose to omit monomorphization, if the code is unused. If monomorphization can fail, the compiler needs to compute some unused monom

Currently the compiler can choose to omit monomorphization, if the code is unused. If monomorphization can fail, the compiler needs to compute some unused monomorphizations, just to ensure they don't raise an error. This could hurt compile times. Otherwise you get compilation failures that depend on the exact way the compiler decides which monomorphizations are used. Plus otherwise semver compatible changes in a dependency can surface latent monomorphization failures, breaking the build. However I do overall agree with you, that rust needs to accept post-monomorphization errors. I see no way to get usable const-generics otherwise.

j-pb 3y ago
Yeah, It's not that I don't see the advantages. I wish that there was a way to get our cake and eat it too. Maybe we can dependently typed eat our way through to the other end, where while we do have monomorphization errors, having constraints on generic types feel natural and ergonomic, much more like in a system like Lean. I think what it boils down to at the end is where you want your pain to be, pains from constantly hitting limitations and providing an escape hatch like macros, or pains from having a system that is too powerful and all the chaos that brings. I'd rather reign in the chaos, after all we also choose to be Turing-complete, and not always terminating like Coq, but mmv.