Thinking out loud, this would be easier to me (made up example):
Before we switch topics, I'd like to summarize the last one, while not closing the door to its extension, given that you promised me "more feedback". Your initial concern, that I recognize as legitimate, can be summarized as: Do the established design improvements ( code reuse, orthogonal features, open for ext ) that I claim provide benefits the user, within the quite narrow mandate of this library? To this end I compared a hypothetical sequence of unit tests using STL, to another using V2. Pending your feedback, I have not seen a refutation, only that "I don't know work a lot with copy 'n' paste", which does not rule out that sometimes you come across something similar, or that someone else might have to do such repetitive work. Mind you, V2 does not purport to be a swiss army knife. Let me rephrase the narrow mandate: "Its core utility is a compact interface for executing the repetitive tasks of assigning or inserting elements in a container" Even as I'm the one under scrutiny, today, I'm going to say that having to study the documentation is not a receivable criticism. Having said this, there is quite some leeway to rethink the interface to be more friendly. At this stage, I would rather hear suggestions about "how", and thank Paul Bristow for doing so. You do acknowledge that the "library can build complex generators/converters of some kind", which has some good in it, I suppose, but go on to criticize that "it's integration with the containers appears ad-hoc.". First, please clarify "integration" since it has come up a few times. Second, your reasoning rests on hypotheticals (would): "The above would allow me to only focus on how to configure the generators, and use my old-time knowledge on how to use these with std::containers.". The proposed library *is* in existence...