[SuperV1234]

Many, if not most, useful libraries, languages, and tools have weird hacks and corner cases in them that look esoteric and insane from the outside.

The reasonable engineer understands why they exist. The engineer with a hate boner or negative bias for a particular technology jumps on the opportunity to make a generalized statement.

I'd rather not be friends with the second kind of engineer. :)

[htobc]

Okay so why not _discuss that_. You're N posts deep in a thread where I've been actively trying since the start to pull this away from a language flame-war, (and acknowledge your bizarrely anti social style of interaction) while again pulling the conversation back towards actually being about constexpr, and all you can say is anyone who criticises it is too stupid to understand it.

I think it's telling that you are quick to respond to my superficial meta discussion, but have left the one reply up the chain about this being the "third reflection standard from the C++ committee" conspicuously unaddressed. Gotta dodge saying anything real at all costs? Or just trying to get your rocks off with an internet fight?

[SuperV1234]

It's quite simple: statements such as "In the real world I would think trying to do any of the things discussed in this article should be an automatic commit rejection on any project." really piss me off.

I find it ironic that you try to "avoid a language flame-war" by implying that anyone writing code like the one in the article, no matter how niche the reason/situation, is a moron.

[htobc]

I have tried to make it clear in my posts that I like and use C++. This is not a language flame war, it's criticism of a feature's implementation.

I did not say anyone using this is a moron, I said I believed a commit exercising the niche edge cases demonstrated in the article should be rejected. In fact, had you asked, (instead of jumping to saying I was too stupid to understand what I was reading) I would have said you need to be very smart to write code like the examples in the article, and that's the reason I would reject it.

Sure it's fine and even fun to exercise these relatively recently released features and really explore the niche edge cases in a personal project, but they are a future maintenance headache in team based software development. The kind of compile errors walked through in the video are simply not where I would want my team spending effort debugging on any given day of the week.

Metaprogramming was not invented in 2020. There are a dozen different ways to get those optimizations in front of the compiler. They might not be as theoretically pure, or might not be using first order features of the language, or might have to sacrifice parts of the static analysis flow, but the trade offs are more than worth it when it comes to delivering.

[SuperV1234]

You shouldn't use what's demonstrated in the article in a random commit in the middle of business logic.

But even in a real-world project, using this technique might have value as part of an internal implementation detail of a useful component that leverages C++26 reflection.

"trying to do any of the things discussed in this article should be an automatic commit rejection on any project" is a very strong statement that suggests you won't even care about the particular situation. It implies that, as soon as you see something that you deem overly weird, you immediately reject it without considering why it is weird and if that weirdness is needed to achieve a valuable goal.

Even in a mature and robust project there is room for esoteric techniques if well justified, commented out, and weighed against alternatives.

To give you a realistic example: you can reflect on struct data member names even if C++20 if you parse __PRETTY_FUNCTION__ at compile time. This is what Boost.PFR, Lahzam, and my own MiniPFR libraries do.

It's what a common developer would refer as "disgusting", "weird", and what would prompt the average C++ hater to take the opportunity to bash the language and remind the world how they think that the Standards Committee is a bunch of incompetent people. Not saying this is what you think, but you see where I'm coming from.

If people had applied blank statements like yours and decided that any code parsing __PRETTY_FUNCTION__ at compile time "should be an automatic commit rejection on any project", we wouldn't have a genuinely useful feature that allows us to reflect data member names in C++20, six years prior to having official reflection.

Yes, it's an esoteric technique. It's a hack, a workaround for a language limitation or language design failure. It's "experts-only" or whatever. Exactly the same way you feel about what the article demonstrates.

Yet, there was a good use case for it -- a very useful and valid one.

Outright banning certain techniques because you cannot understand how they could be valuable in very specific scenarios is honestly infuriating. Obviously, the use of niche/dangerous workarounds should not be liberally promoted. At the same time, automatically rejecting any commit is an insult to the intelligence of the person who wrote that code: perhaps they had a good reason to write it that way.

[Dylan16807]

> Outright banning certain techniques because you cannot understand how they could be valuable in very specific scenarios is honestly infuriating. Obviously, the use of niche/dangerous workarounds should not be liberally promoted. At the same time, automatically rejecting any commit is an insult to the intelligence of the person who wrote that code: perhaps they had a good reason to write it that way.

The problem with this discussion is that you pulled "because you cannot understand how they could be valuable" out of nowhere. They're talking about rejecting it despite the value. You should not be infuriated for that reason.

If there's an insult based on intelligence, it's saying they're too smart and need to write something dumber so that more people can maintain it.