Emulating private function in traits

help
13

Yes, our soulutions are pretty much the same indeed :smile:. That being said:

  • Documentation-wise, I like to see in the rendered docs that the return type of a trait's method (that, in practice, is just an impl Display) be named something like implDisplay. Hence my usage of helper modules to avoid name clashing, and factoring all that with a macro (of course not necessary);

  • You have chosen a design where a TextFormatter instance is deprived of runtime information (no &self parm; only type-level / compile-time information). I was tempted to go in that direction too (it is, imho, more elegant to stay in the type-level realm), but at the end of the day, I chose to use unit structs with &self state available instead, even if I'm not using it anywhere. This is because, if later on, someone realises they need an instance with runtime state, it is easy to add a struct ... {/* state */} impl TextFormatterImpl for ... to achieve it, where in the pure type-level case a rework would be necessary.

  • You have used an associated type (Self::Self_ : Impls) where I haven't; I hadn't thought of doing that, to be honest. I even think I prefer your associated type approach a bit more, since it is more "compositional" rather than inheritance-based :slightly_smiling_face: ; but it relies on the state-less property I mentioned (otherwise you'd need to add a get_Self_(&self) -> &'_ Self::Self_ or something along those lines).

Overall, I think the fact we have arrived to the same solution has been indeed quite interesting, so as to compare the little differences between the two approaches.