On Fri, Dec 18, 2015 at 11:50 AM, Nevin Liber
On 18 December 2015 at 10:37, Stefan Seefeld
wrote:
On 18.12.2015 11:20, Nat Goodspeed wrote:
Am I overlooking a generic boost::make<something>() of this general form?
Given the small amount of code potentially to be reused, what would be the advantage of having a generic version ? The goal of abstraction should be clarity, but more often than not, generalizing code rips off not only unnecessary details but also its meaning, making the code harder, not easier, to understand.
I disagree. The make_* functions are just noise, and I'd love to see a generic one. While return type deduction has made it somewhat easier to write these functions, a generic one would be superior.
Nevin speaks truth: the make_SomeTemplate() functions in our code base are just boilerplate. More importantly, encountering make_SomeTemplate() in the code *increases* the cognitive load on the maintainer. What does make_SomeTemplate() do? Oh: it returns an instance of SomeTemplate<deduced args>. Every such call requires an indirection: the maintainer must look up make_SomeTemplate() to discover its role. If we introduce a std::make() template function, that becomes part of the maintainer's working vocabulary. S/he only needs to look it up *once*. You could reasonably argue that a consistent naming convention (make_SomeTemplate() should surely return an instance of SomeTemplate) nearly eliminates the cognitive burden. And you'd almost be right -- if we could trust that no such function ever snuck in any side effects. :-( I would counter that std::make<SomeTemplate>() is an even clearer "naming convention." Moreover, I could be pretty confident that std::make() would have no undocumented side effects. I applaud Vicente's work at https://github.com/viboes/std-make Vicente, would you be willing to float the library via Boost?