[htobc]

Hey buddy, maybe not liking something is not the same thing as not understanding it? Maybe saying, "this specific feature is bad" is not a generalization to the entire language? Maybe niche corner cases are evidence of poorly chosen primitives and bad design? Maybe jumping straight to smarm and skipping past actually defending the feature means you probably create a work environment no one wants to be in? And an esoteric paradigm like "constexpr two-stepping" that is explained in the article by linking a video that is _over an hour long_ is a perfect example of something that, while perhaps the author and demonstrator explored more for fun instead of as a serious thing to do, would only ever be put into a production code base by the most amateur of architecture astronauts, shortly before their startup fails?

For real though, defend constexpr two-stepping as a real use case for serious people.

Or did you just get a little bit confused and think the criticism here is actually coming from people who are out of their depth from hearing "compile time optimization" or don't know what reflection is?

[SuperV1234]

> would only ever be put into a production code base by the most amateur of architecture astronauts, shortly before their startup fails?

Yep, definitely failure of understanding. :)

> For real though, defend constexpr two-stepping as a real use case for serious people.

Of course, here's a use case: I am a serious person developing a library that provides a nice API to solve a real-world problem using C++26 reflection. As part of the internal library machinery, I need some temporary storage for some compile-time algorithm (e.g. building a graph for automatic parallelization, or some other thing like that). In an internal helper function of my library, I use constexpr two-stepping to solve the problem without imposing hard limits on my algorithms and keeping the final API as simple as possible for the end user.

Then I submit my PR, but htobc reviews it and immediately rejects it, ignoring the real business value of the library because I made a conscious engineering decision to use a niche technique to solve a language limitation as part of my library implementation.

Then my startup fails.

[htobc]

And then it turns out after ignoring any attempts to actually engage in the technical merits of how constexpr is done in C++, you made it 25 minutes into the 1 hour video, past all the obvious jokes from the presenter about how absurd it is to try and use the feature, where it turned out that it wasn't supported in your tool chain. Then you realized you were weirdly obsessed with making sure no one ever criticises anything about C++ and it turned out your real special interest was not having friends.

(There are far simpler ways to do that.)

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