I posited roughly the same functionality previously as macro fn, using T: _ to specify a generic as what is called here "weakly bound." The trick is that you need instantiation-time[1] resolution/checking for any "weakly bound" generics for them to be of any real use. If you want "inferred bound" behavior instead, the use of a "weak" generic cannot use method syntax (or other auto(de)ref sugar) and can only be a function argument (including to operators which are auto(de)ref-free trait function call sugar).
I still believe that macro fn has a niche, and would be a stronger alternative to expression position macro_rules! more than a weaker alternative to generic fn.
Rust generally would call such a post-monomorphization error, but I find that conflating "during monomorphization" errors (e.g.
constevaluation panics) with "after monomorphization" errors (e.g. codegen/linker) errors to be a mistake. (IIUC,constevaluation errors are the only "during mono" error which is currently handled "post-mono".) The important difference is that post-mono errors may be hidden by optimizations which bypass monomorphization (includingcheckonly doing pre-mono checks), but I believe instantiation-time errors should always happen. (IIRC we're measuring what the cost would be before stabilizing inline const, which makes const-instantiation errors significantly more accessible.) ↩︎