SuperV1234

The main problem, however, was code quality.

The sleight of hand misdirects the reader away from the main way bugs are eliminated: by dedicating engineering resources to it.

Perhaps the amount of bugs comes from using a C-like language that requires meticulous manual care to avoid writing runtime bugs.

Even C++ would be a safer choice because of RAII.

When you have to dedicate significant resources to avoid/fix runtime issues that are made impossible at compile time by other languages, the programmer isn't entirely at fault.

Is that all that Mythos did?

Did it find any real potential issue, optimization/simplification opportunities, or sparked any thought-provoking discussion within your organization?

Or was it purely a net negative experience?

How does this compare to frontier models?

Data Oriented Design rocks. It was the subject for my CppCon 2025 keynote: https://youtube.com/watch?v=SzjJfKHygaQ

It's not that simple.

The grandma that would have phoned her nephew to fix the phone will still do the same thing now. She will not have magically switched to querying LLMs after a lifetime of technological illiteracy.

The tech-savvy person that uses AI today would have been more than capable than figuring out how to fix their router by using Google even without prior networking skills/experience 5-10 years ago.

Using AI to solve these problems is a novelty for a specific subset of the population. And the topic does matter.

Even the somewhat tech-illiterate mom would have been able to Google a recipe 10 years ago, or watch an Instagram reel 5 years ago. They were surely not going to call their friends to ask instructions on how to make an apple pie.

Pretending this is an AI novelty is indeed disingeneous.

How'd you infer that I don't find AI useful from my statement? Of course I do. I am merely saying that the argumentation in the "poem" is not specific to AI.

And if my router wasn't working 5 years ago, I would have first used a search engine and tried to figure it out on my own.

Pretending it's an AI novelty is... disingenuous.

I found this quite cringy and an attempt at pulling at one's heartstrings due to the lack of a strong argumentation.

I wouldn't have called a friend for a meal plan or to figure out a hiking path 10 years ago, I would have used a search engine.

If I want to talk to a friend, I don't need an excuse to do so. And I'm not going to waste their time by asking something I can easily figure out on my own, today with AI, years ago with Google, and prior to that with printed material.

The anti-AI craze is just as bad as the "AI will solve everything" crowd.

Finally, a sane policy.

Very interesting, this is the first time I hear about segmented iterators and hierarchical algorithms.

I faced a similar issue myself when implementing a chunked vector a la `std::deque`, but opted for callback-based internal iteration, i.e.

    void ChunkedVector::forEach(auto&& f)
    {
        for (auto& chunk : chunks)
            for (auto& item : chunk) 
                if (f(item) == ControlFlow::Break)
                    return;
    }

    enum class [[nodiscard]] ControlFlow : bool
    {
        Continue,
        Break
    };

It's sometimes inferior in terms of ergonomics, and cannot express more complicated algorithms or iteration patterns (e.g. partial range, going backwards), but so far it has served me well.

Just something to consider if implementation simplicity is the priority and there's no need for a very generic suite of algorithms.

Boxed, and needs complex incantations to avoid the boxing. Meh.

That's a strange dismissal. `Optional<T>` isn't "perceived" safety -- it eliminates a whole category of bugs (null dereferences, uninitialized reads) at the type-system level, with zero runtime overhead versus a raw pointer or sentinel value.

If you think that's uninteresting, that's an aesthetic preference, not a technical argument.

But let's set that aside, because it's also irrelevant to the compile-time claim.

The point of the example wasn't "look at this fascinating class," it was "here is a real template, used 911 times across the codebase, in a public header -- exactly the scenario you said would be slow -- and it costs under 1ms per instantiation."

You can swap `Optional` for any non-trivial template of similar complexity and the numbers will look similar.

On your 1 MLOC/sec benchmark: that's a fair reference point for C-like code, but it's not the right yardstick for template instantiation, which is doing semantic work (overload resolution, SFINAE, constraint checking) that a C compiler simply isn't.

Comparing them is comparing different jobs.

The honest question is whether template compilation is slow relative to what it's actually doing, and in well-structured code, it isn't.

And yes, `Optional.hpp` is a header -- that's the whole point of the demonstration. I'm not claiming you should hide every template in a .cpp file. I'm claiming that even templates in headers, instantiated hundreds of times, are cheap when written with compile times in mind.

The "put templates in .cpp where it makes sense" advice is for the specific cases, not a blanket rule.

So? The original argument was about the "ugly" syntax that the user didn't want to interact with nor read. I proved that there's no need to do so to consume reflection utils.

Alright, I'll bite.

This is my `sf::base::Optional<T>` template class, a lightweight replacement for `std::optional` with same semantics: https://github.com/vittorioromeo/VRSFML/blob/master/include/...

This is what ClangBuildAnalyzer reports:

  **** Template sets that took longest to instantiate:
     833 ms: sf::base::Optional<$> (911 times, avg 0 ms)

I'm sure I can optimize it even further if I wanted to.

---

Now to refute your other incorrect claims:

The point of templates is generic programming, reusable components.

That's ONE use case. A more general use case is just reducing code repetition in a type-safe manner, which is extremely useful even within the same translation unit. Another use case is metaprogramming. And I'm sure I can come up with more. Templates are a versatile tool.

And if you have to "selectively pick TUs where they're instantiated", you're basically admitting that you have to invest effort to reduce compile times.

...well, yeah? Of course you have to put in effort to reduce compile times. That doesn't undermine my point at all.

C++ templates are not slow to compile.

I'm bullish on LLM-assisted development but this is just a very stupid way of performing such a critical migration.

That's just false. Templates are not slow to compile at all, and you can selectively pick TUs where they're instantiated.

My entire VRSFML codebase compiles from scratch in ~4s and I liberally use C++ features, I just avoid the Standard Library most of the time.

Templates are not inherently slow, people just don't know how to use them and don't know how to control instantiation.

Most people still think that templates have to go in header files, which is also just plainly false.

This is a myth, C++ is not inherently slow to compile. It's the standard library that is very bloated and the main culprit for slow compilation.

Utter BS. Compilation times matter for productivity, developer motivation, iteration speed, CI turnaround time, and so on.

I'm sure you wouldn't say "it doesn't matter how long it takes to compile" it if took days. So where do you draw the line? Regardless, it matters.

No, it objectively isn't objective.

Package? We're suggesting to copy paste 5 lines and stick them into a header.

  #include "to_enum_string.h"

The parent comment is quite clear:

Why do I have to be familiar with all those weird symbols just to do a trivial thing ?

And my answer demonstrates that you do not have to.

It works generally, but not with expansion statements. See section 3.2 here: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p13...

It seems that this is being worked on, and eventually the `define_static_array` won't be needed anymore

To be honest there are ways to make that much nicer. I believe that if you use recursive macros using the VA_OPT feature, you should be able to provide enumerators directly to define enum as a list.

The underlying machinery implementation is going to be much uglier and complex, though.

See https://www.scs.stanford.edu/~dm/blog/va-opt.html

By your logic we shouldn't ever use external libraries.

PFR has given us reflection since C++14.

I also don't think the Standard Library is particularly well-defined nor well-implemented, as demonstrated by the atrocious compilation times.

It is kind of weird at first but the reason is that `std::vector` requires heap allocation and transient allocations are not allowed in `constexpr` contexts. The purpose of `std::define_static_array` is to promote the storage of the vector to static storage to eliminate the transient allocation issue, and so that the `template for` can work properly with it.

See wg21.link/P3491

This cost is not significant nowadays, it's the frontend/parsing time.

You can also use `#pragma once` which works everywhere, is nicer, and technically needs less work by the compiler, but compilers have optimized for include guards since a long time ago.

Some random measurements I found: https://github.com/Return-To-The-Roots/s25client/issues/1073

It's a fair comparison. The parent comment isn't showing the compiler source code for the built-in reflection mechanisms.

You won't have to care about ^^ and [:X:] if you just want to consume reflection-based utils, which was the whole point of my comment.

C++:

  enum Color { red, green, blue };
  auto name = to_enum_string(Color::Red); // "Red"

...so what? It's just a header you have to #include.