That's why I do such things in my language in a different way. Optional and union types are just library container classes. More methods may be added if necessary, internal layout may be changed, etc. without changing the language core itself. But in such an approach the language itself should provide necessary means allowing creation of such library abstractions.

  var value = maybeValue.notNil // I know what I'm doing

It's not true for typical use-cases, when objects aren't processed one by one, but in bulk.

> Next, you have type bloat

What's the problem? Do you pay a special tax each time you need create a new type?

> Prepare for a lot of this

That's not how it's done in C++. You typically have a template for handle types, so that PlayerHandle is just Handle.

> Handles are also a lot bigger.

The article mentions, that handles are typically smaller than pointers. A pointer is 8 bytes (on 64-bit machines), but handles can be smaller if not so many objects are needed to be created.

> Next, you have the issue of resizing your memory array.

There is only problematic to resize it down, which is almost never needed.

> dozens of arrays

> manage the lifespans and scope of all these object pools

It's not a problem. Each subsystem owns its arrays and destroys them only when the subsystem itself is destroyed.

Same for other responses. Great, you can just implement a lifespan array in every subsystem. If your sub systems are very simple (e.g. single Entity component is the only thing you're allocating in a game, maybe Resource as well), then sure, its simple. Not sure what it's buying you, since you apparently are also freeing all entities and scene elements at once too. But for a complex system where there are many types of objects (dozens or hundreds), and where lifespans are complex (some short, some long), then having "every system implement its own pool" adds a lot of complexity. Then not only would you want type-safety with a Handle

Knowing that Github is owned by Microsoft, they probably are fine with it.

But I agree, that using an "AI" tool may be a serious temptation and thus way less new porting projects will be done with such care.

Is there such thing as "community" at all? As I know, the majority of open-source projects are developed by a single person, where others only contribute bug reports (in best case). It's not a community, if there is such imbalance in contribution and power.

Only a handful of projects (a small percentage) has actual community with many members doing meaningful contribution. But they are most notable ones, so that one may think, that all open-source projects function like this.

Every single time this comes up it turns out that 'community' is just a trojan horse for 'group of people that sign off on whatever I want and enforce my personal opinions on others'

Now, the number of projects is not that important since we are talking about people. In my entirely unscientific estimate, the majority of FOSS developers is mainly active in a project of more than ten people.

  for( size_t i_plus_one = count; i_plus_one > 0; --i_plus_one )
  {
      const size_t i= i_plus_one - 1;
      // actual loop code
  }