It always seemed to me that it should be relatively not difficult to write some kind of language that limited you to the "right" way of doing things and that compiled down to C++

You could:

- prevent people from using deprecated features

- immediately remove TONS of boilerplate

- automatically generate header files from the cpp's

- have high level keywords that would generate design patterns for you (no more having to re-implement a Visitor for the first time that year and having to spend a day debugging it)

At the same time you could still leverage C++ libraries and when you do need to write an allocator or do some fancy diamond inheritance friend method templating magic shenanigans you could always drop back down to C++

EDIT: What I find kind of amusing is that with time you can do more and more of these things through Visual Studio's magical "wizards" and checkboxes (maybe it's the same for the other IDEs.. not sure), but ofcourse it's rather silly, clunky and slow to use. In the latest version you can finally make matching declarations/definitions with a couple of clicks - saves a lot of the mildly frustrating copy/past'ing!

You might like http://felix-lang.org in particular if you have a taste for the ML family of languages. It fits your description to a T. No, really, dead serious and I don't have any dog in this fight. Has had coroutines and fibres from the start. Certainly not a new language. Its relationship to C++ is much like F#'s relationship to C# or Scala's to Java

OTOH if you are really after C++ but done right then that would be D http://dlang.org

If you wish something like this for C then I would likely point to Nim.

What you're describing basically already exists, it's Rust.

that compiles to C++ and has 2 decades of libraries and tools written for it?

Rust compiles to LLVM IR, which is better than compiling to C++ (for reasons I've elaborated on before).

As for library and tool support, I think a safe subset of C++ couldn't actually use tools for "real" C++, because the languages would be too different.

I'm sorry, but I feel like all these "Just use Rust!" comments are written by idealistic college students.

Yes, maybe Rust is better, and maybe if we could push a button and make everyone use it the world would be a better place.

But the reality is that there are very few code bases written in Rust and an uncountable amount written in C++ - there are decades of work behind C++ and decades of work will still be done in C++. I need to earn a living TODAY and work in the current reality, and I need tools to help me be more productive. I can't wait 5 years for some brand new language to take over.

I think you're misinterpreting what pcwalton said. Sure, seeing "use Rust" in every possible place is quite annoying, but what pcwalton described is why "compiles to C++" and "has 2 decades of libraries" don't work for new languages. He didn't say to use Rust, he was just pointing out that your two ideas aren't viable.

> But the reality is that there are very few code bases written in Rust and an uncountable amount written in C++

Most libraries use a C ABI due to it being stable, and Rust has fantastic FFI support for C (although tools to take in a .h and spit out the FFI in Rust are definitely needed). There's no performance cost to FFI in Rust, either, it's just a function call. As someone that spends a lot of time in an existing C++ codebase, FFI with zero overhead offers a very enticing migration path.

But as you were asking about making a new language, I was just pointing out the language you were starting to design has already been built.

But wouldn't factoring out the obsolete features limit the libraries that are available to use? I thought that was the point of the newly developed systems languages. Even if you follow some "sane" parts of the language, the rest of the ecosystem won't agree with you. Just look at this thread, there are tons of disagreements in what a good C++ code is.

See also http://www.stroustrup.com/SELLrationale.pdf "A rationale for semantically enhanced library languages" by Bjarne Stroustrup: "A Semantically Enhanced Library Language (a SEL language or a SELL) is a dialect created by supersetting a language using a library and then subsetting the result using a tool that “understands” the syntax and semantics of both the underlying language and the library." "The basic idea of... SELLs... is that when augmented by a library, a general-purpose language can be about as expressive as a special-purpose language and by subsetting that extended language, a tool can provide about as good semantic guarantees. Such guarantees can be used to provide better code, better representations, and more sophisticated transformations than would be possible for the full base language. For example, we can provide support for parallel operations on containers as a library. We can then analyze the program to ensure that no undesirable access to elements of those containers occurs — a task that could be simplified by enforcing a ban of languages features that happened to be undesirable in this context. Finally we can perform high-level transformations (such as parallelizing) by taking advantage of the known semantics of the libraries."

I thought about this too and started to write down some ideas: http://bixense.com/coffeepp

In the end though I never had enough time to bring it to a usable state, it was just a toy project for me to play around with waf-build and boost.test.

I think D is a better C++, and just for my bias confirmation, some things I read in the C++ guidelines are clearly influenced by D, or easier to do in D.

It doesn't compile to C++, but directly to machine code.

I think it's worth observing that a number of these are just common-sense guidelines for good programming practice, rather than being specific to C++. For example:

"Use exceptions for error handling only"

"Avoid data races"

"Prefer a for-statement to a while-statement when there is an obvious loop variable"

"Don't pass structured data as strings"

"Eliminate redundant indirections" (for performance)

and so on. These don't really lend themselves to automatic checking, but it's still nice to see them written down in one place along with the more language-specific stuff.

Of course in Python, you're encouraged to use exceptions as part of the normal program flow.

(For example in duck typing, rather than checking whether your value is of a certain type, just assume it is, and deal with possible exceptions if it isn't)