4 ms·
I wonder if we really need an explicit syntax or if the compiler just need to disable monomorphization for functions that don't use the interior type e.g., only
by eximius 3y ago
I wonder if we really need an explicit syntax or if the compiler just need to disable monomorphization for functions that don't use the interior type e.g., only passing around references like this example.
Without trait bounds there isn't much you can do with it anyway besides generic code like this. I guess the question is 'does Rust emit' or elide an unused generic function with unused interior types?
- Ericson2314 3y agoExplicit syntax is much better. "Just infer it" means we have to trace entire call graphs, because we have to know if our callees need monomorphization in order to know if we need monomorphization.
- jcranmer 3y agoIt's... not the most compelling feature in the world. The main use case I think I see is slightly easing the burden of writing external function signatures for a function that passes a user-definable type to a function callback parameter like qsort does. But there's relatively few of those functions in existence, and often times, you want a more ergonomic function definition anyways (see e.g. https://news.ycombinator.com/item?id=39267277 https://news.ycombinator.com/item?id=39267277 for qsort). The other major use case is if you've got something like a Vec<T> where several of the helper methods can be erasable. But it's already possible to do this with helper functions--the standard library takes advantage of it--so it's not entirely clear that you need a language-level feature for this use case.