> Meanwhile there appear to be many people who (I must admit much to my puzzlement) seem to still enjoy writing C++ and want to add even more features and paradigms to it.

I enjoy C++. My general approach to programming is that you should make a domain-specific language to express your problem, and then solve it in that DSL. C++ is a good tool for that when you also need deterministic performance guarantees. So any "new feature" that allows me to write more expressive DSLs is welcome.

"It's called D. It's called Rust. It's called C#. It's called Go"

All of these languages with the exception of D are completely different. It's like saying you fixed a cupboard by replacing it with a sofa.

D's the most similar, but it's sadly not exactly a hot language or one where there's jobs available.

Was the cupboard being used as a sofa?

* rid of all the legacy baggage * It keeps being repeated over and over but where can I find such a list? There's almost no misfeature in c++. It's issues are just the fact it's too low level / manual.

How is it too manual compared to eg C# where I need to implement IDisposable and wrap use of variables in "using" to really ensure something is cleaned up when I want it cleaned up (without risky memory ballooning relying on the GC)? C++ destructors to clean up your resources are really neat. And deterministic - you know when stuff is going to get cleaned up.

Or was it some other "manual" feature that's too much of a burden? Honestly curious.

Here's a non inclusive list

1. Initialization

    Type foo = Type(FieldType())
    Type foo = Type{FieldType()}
    Type foo = Type { .field = FieldType() } 

2. std::unique_ptr can be null

3. std::shared_ptr does not guarantee atomic reference counting

4. std::variant and std::optional require exception handling.

5. std::map should be the std::unordered_map data structure, while std::ordered_map should be the special case. The unordered_map should also stop being a terrible hashmap implementation on most platforms.

6. std::vector<bool> is not what you think it is under the hood

7. Explicit should mean the opposite when it come to single argument constructors (meaning implicit casting needs to be explicitly enabled in the constructor definition)

8. Although on that point, one could argue that implicit casting should be a different operator overload than constructor definition.

9. There needs to be a mechanism to check the validity of a template argument before the template is expanded (concepts will fix this, iirc)

10. https://codegolf.stackexchange.com/questions/1956/generate-t...

11. It should be trivial to implement an std compliant iterator. It is not: https://stackoverflow.com/questions/8054273/how-to-implement...

> std::unique_ptr can be null

what would be the difference between a never-null unique_ptr and a reference ?

> std::shared_ptr does not guarantee atomic reference counting

is that a problem in practice ? all implementations do use atomic reference counting. Just because it's not written in the standard does not mean that common sense does not apply.

> std::variant and std::optional require exception handling

exception is the standard way to report errors in C++

> std::map should be the std::unordered_map data structure, while std::ordered_map should be the special case. The unordered_map should also stop being a terrible hashmap implementation on most platforms.

Anyone who has a problem that calls for caring between unordered_map and map will know the difference, and for everyone else, does it matter ?

My opinion on that is that standard library types do not really matter - I use 3 different non-standard map implementations for specific use cases in one of my apps and there is zero friction as maps are almost always an implementation detail, it is nigh uncommon to e.g. have an API that takes / returns maps.

> std::vector<bool> is not what you think it is under the hood

that depends on who you ask :p from past teaching experience, if you ask students to tell you what is vector<bool> they will tell you that it is packed because it feels like the logical thing to do.

> https://codegolf.stackexchange.com/questions/1956/generate-t....

turing-complete language can generate arbitrary things and is not immune to halting problem, news at 11 :p

>what would be the difference between a never-null unique_ptr and a reference ?

Ownership.

> all implementations do use atomic reference counting

They do not.

> exception is the standard way to report errors in C++

Not really, at least in practice. Many C++ developers do not use exceptions at all, with good reason.

>turing-complete language can generate arbitrary things and is not immune to halting problem, news at 11 :p

The point is that a relatively simple syntax error on behalf of the programmer generates an incomprehensible error message. This is just a comical example of that, and a lot of real world code using templates is full of opaque errors at the start. That said, concepts should help eventually.

I don't have a list, but initialisation is quite a mess and the syntax inconsistent. That would be one of the first thing I would fix in C++.