[dymk]

What a neat concept. It never ceases to amaze me what people can arm-bar C++ into doing through typesystem, metaprogramming, and operator overloading shenanigans.

I hope I never see this in a production codebase, though!

On a kind of related note, I want to see an alternate history where C++ had support for Rust-ish proc macros, or Racket-ish macros. What would that language even look like? There'd probably be no need to hack existing C++ language semantics to add new features, you'd "just" generate the code that the meta-language lowers to.

[Longhanks]

> 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++.

[dymk]

I say that because I would hate to be the person that has to ramp up a junior engineer on a project that uses a library like this.

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.

[Longhanks]

> 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.

[dymk]

Right, well, I think we can agree the committee makes some weird calls sometimes with respect to language design. We only got concepts and coroutines (relatively) recently, and they're still kind of warty. `std::range` is beautiful and I'd still only use it sparingly. The C++ language, in my experience, is a language best served as a safe subset with "magic" and advanced features eschewed as much as possible.

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.

[UncleMeat]

I wouldn't even say "kind of warty." I think that Titus Winters was spot on a few years ago that he predicted that concepts are unrefactorable in sufficiently large codebases.

[spkm]

It's my impression that people tend to underestimate "junior engineers" in the C++ world. I'm always impressed at conferences that there are so many young people holding presentations about really advanced topics.

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.

[dymk]

Those people giving talks at conferences are the best of the best. 99.99% of people who write C++ have no interest in the arcane depths of the language, and would rather things "just work" over having a library that does something cool, but hard to debug when things go pear shaped.

[Kranar]

Not all, the people giving talks are just people who happen to be interested and curious.

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.

[Kranar]

It's interesting you mention junior engineers. My experience is the complete opposite, it's people who have been programming for many years who hate learning stuff like this and want to stick to their comfortable way of programming, whereas those who have programmed for fewer years enjoy learning about this and actually have fun doing so.

Perhaps unsurprisingly the author of this library looks to have only a few years of experience themselves.

[dymk]

It may be fun, yes, but I've found that experienced engineers aren't eschewing libraries like this because they hate fun and learning new things.

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.

[kubb]

You think a junior can't understand how this library works and use it safely?

[dymk]

In my experience, which was introducing engineers at Facebook to "fancy" C++ stuff, no.

[pclmulqdq]

In my experience at G introducing modern C++, the most senior engineers had the biggest problems with it. Junior engineers hated the cryptic errors a lot more, though.

[spkm]

TBF, everyone hates these cryptic errors :)

[UncleMeat]

I'm mixed on this. On the one hand, I agree with you. Well isolated systems can be messy internally without causing trouble. On the other hand, error messages. STL has famously awful error messages. I do want to know what the compiler will spit out when I've got a syntax error or a type error when using one of these constructions. Because teaching people new to C++ what "you stuck a non-movable type in std::vector" error messages look like is not a trivial task.

[formerly_proven]

> Do you also hope to never see the STL in production? Because internally, that thing is high level unreadable C++.

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).

[robbintt]

The Define problem seems like low hanging fruit for a linter/formatter.

[gpderetta]

That alternative history is currently being implemented by the Circle compiler.