My code has lots of type parameters and I'm running out of letters that make sense. Is there some established convention for naming type parameters with more than a single letter? Which do any idiomatic codebases use such a convention?
libstd has gems like this:
impl<T0, T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11> Debug for (T0, T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11)
but I think the convention is to limit use of generic parameters to no more than 2-4
That's not practical in my case, because I have a facade struct that's composed of many different types (4-6), and that struct has a facade trait implementation to avoid having loads of
where predicates on every item that uses this facade. It would be nice to find a way to break it down, though.
There's no real reason why type parameters need to be one character. It's mainly because single-letter type parameters are shorter and their meaning is evident from context. If you've got so many type parameters that you can't tell what they mean at a glance, maybe it's time to give them descriptive names like any other variable?
For example, in my
gcode crate there's a type called
Comment<'input>. Sure, it could have been
Comment<'a> (the usual convention for lifetime parameters), but I chose to use
'input because it's more descriptive.
If you're creating a facade type, why not use boxed trait objects? The purpose of a facade is to wrap a complex system and provide a simpler interface. If users are needing to make all their code generic and write half a dozen type parameters I'd argue that the facade is leaking implementation details and isn't doing its job.
That is the purpose of the facade. Indeed, the parameters are only necessary in its implementation, the user code only needs one parameter.
Type parameters: concise
UpperCamelCase, usually single uppercase letter:
The more you'd have the more I'd say understandability trumps concision.