YHK - yet another hacker news clone

I follow you, unfortunately given that most Java and .NET implementations aren't bootstraped, there is Node.js, most modern runtimes build on top of LLVM and GCC as their backends, I still have to keep my C++ knowledge relatively of up to date.

That doesn't work if you are writing a library where users of the library are able to implement their own event types.

Even for a self-contained code base, it's a pain compared to a type that just works with any current or future derived class.

  enum EventType {
     ...,
     EVENT_USER_START = 0xF0000000,
  };
  struct UserEventData { uint8 placeholder[64]; }
  struct Event {
     EventType type;
     union {
         UserEventData user;
     };
  }

Typical C approach. In C++ this should be done with std::variant instead. It has the exact same binary layout, but is type-safe (compared to union usage).

What you wrote there is just an unsafe way to do std::variant. This has nothing to do with what the blog post is about.

The blog is about Open polymorphism. Where the list of compatible Object can be extended dynamically (Which is handy for some type of error report for instance).

You can do that since forever in C++ (Since the first support for inheritance), the only thing std::polymorphism brings is the ability to do it without dynamic allocations, emplacement new or lifetime problems.

When this piece of code exists in a library, it makes it pretty much impossible to extend by the user of the library.

Yes, though in modern C++, don't do this, use std::variant instead. It has better type-safety (nothing stops you from writing to one member of the union but reading from another, causing UB) and handles lifetimes much better. Your version leaks, because struct Event wont destruct any of the nested types inside the union, and in the example, they have heap-allocated data (std::strings and the like). In order to that properly with a tagged union, you need to define the destructor of Event yourself (which is not done in your example) and call the correct destructor manually of the active union member.

Tagged unions (especially with resource-managing types) is hard to implement correctly in C++ (and not trivial in C either). Don't do it, use std::variant.

Looks like it depends on the specific operation(s) you want to perform [0]. For instance, constructing a std::polymorphic<T> from an object of type T or derived from T requires that that object is copy-constructible (among other requirements), but copy-assigning one std::polymorphic<T> to another only requires that T is complete.

[0]: https://eel.is/c++draft/polymorphic

> It would've been much more useful to make the move constructor of indirect be deleted

No, that would be less useful. As-is, you can use a class with a `std::indirect<T>` member in a `std::vector` just fine, thanks to the move constructor.

With `std::indirect` in `std::vector`, the vector can use move the `indirect` internally when reallocating, and as a user of the vector you will never encounter the moved-from state.

It's annoying that C++ doesn't have destructive move and thus needs to relax class invariants after a move happened, but in practice it's usually not a big deal because use-after-move is usually a bug, nothing anyone would do intentionally.