> I hope I never see this in a production codebase, though!
Why? Looks completely readable, easy to understand to me.
Do you also hope to never see the STL in production? Because internally, that thing is high level unreadable C++.
Why? Looks completely readable, easy to understand to me.
Do you also hope to never see the STL in production? Because internally, that thing is high level unreadable C++.
I've written my fair share of code like this, and while you and I might grok it (and probably have a fun time figuring out how it works in the process), most people will hit a brick wall the moment they have to debug the 1000 line error that Clang or GCC will give you when there's a type error.
This is the kind of thing that belongs in language-feature land (so you get tooling support, reasonable compiler errors, etc), not library-land.
Again bringing up my STL example: This is just not how C++ runs. I’ve seen my fair share of std::__v1::basic_string<char, char_traits<char>, DefaultAllocator<>> errors. Some would argue a string type should be language-level, and they might be right, but the committee disagrees.
The C++ STL has a lot of templated code in it (obviously), but at least the amount of weird tricks, such as template recursion, is fairly small (ignoring newer additions like `std::range`). And even then, compiler errors can make an experienced engineer's eyes water. At least you can paste most errors into Google and find a relevant StackOverflow post about how to fix it.
Involving a library like this, though - best of luck, the engineer is on their own.
IMHO this "no junior will ever understand that" attitude comes mostly from older folks who learned C++ as C with classes and to whom even the STL is a work of the devil.
This idea that only the best of the best are able to be curious and learn the nature of the tools they use at a very deep level is misguided and furthermore promotes a kind of anti-intellectualism.
It's also a large part of why I think many developers get burned out, imagine working in a culture with other engineers where people are kind of pressured to only do boring work, stick to boring features, only write code in a very narrow manner that satisfies the lowest common denominator using the same old boilerplate over and over again and keep doing that for a decade or longer versus an engineering culture that values people being inquisitive, breaking out of their comfort zone, writing interesting libraries that abstract out common patterns and eliminates painful repetition, and who appreciate the inherent complexity of challenging problems instead of treating it like some arcane voodoo that only the select few can understand.
It makes me so damn glad I run my own company.
Perhaps unsurprisingly the author of this library looks to have only a few years of experience themselves.
Rather, it's because experience has taught them that the looks-cool slightly-magical stuff like this is hard to maintain once a codebase reaches a certain size, and maintainable code is boring and obvious.
Thank you GCC for telling me that I'm missing a copy/move constructor (can't remember which it was). Clear as mud as always. At least with the several pages of template instantiation errors you can scroll to the top where useful information can sometimes be found.
SGI/HP STL isn't nearly as bad as modern implementations, though they all __share _Weird ____identifier names, mostly because of C/C++ identifier rules (_[A-Z] and anything with __ are reserved for the implementation, everything else might just be #define'd to rick-roll by whatever program is including you).