Sigh.
So there's already like 50 of these things. C++, D, Go, Nim, and Rust are even _popular_ ones, not to mention all the barely-known ones. Not to mention all the languages that don't even pretend to be C-like.
Garbage collection: Garbage collection in its current form is un-operable: However, we have come up with some ideas for garbage collection that would be very good, clean, and would not affect performance in our major use case. Essentially a garbage collector that only runs when you need it to (idle hook) and can be preempted (interrupted) at any time to process higher priority events. Once the system is idle again, the collector resumes where it left off. This is actually possible. The major hurdle is that the C language does not support the reference tracking we need to implement it.
I think you have a major misconception about how GCs work. Also, even in the most modern of GC'd languages, developers working on things like games basically have to avoid half of the language in order to 100% guarantee they do not trigger the GC. It's actually _less_ convenient than using C!
Not that it matters, because a language that helps you track object lifetimes (C++, Rust, D, etc.) gives you automatic memory management without ever needing a GC.
Plus, GC's are totally useless for anything except _memory_ resource management, which is hardly the only resource that needs lifetime tracking, so the non-GC automatic lifetime mangement features are in fact more powerful. Which is exactly why lnaguages like C#, Python, D, and so on had to add half-measures like 'with' statements and IDisposable objects (which unlike in C++ or Rust, are easy to misuse and accidentally leak resources, or at least lose the very necessary predictable destruction behavior).
Get rid of header files.
C++ is gaining this feature. Kinda.
Class model: Right now we employ a very simple class model using C. Basically we 'derive' from structures. This means you can cast any structure to any other structure as long as the structure derives from it. Deriving from a structure means that the first member of a new structure is always the base of another structure. Will need to expand upon this idea; however, the ability to have classes, member functions, etc..
So you want a brand new language that has none of the type theory innovations after the 1970's and also somehow without many of the type theory innovations of the 50's? Neat.
We don't need all the fancy stuff coming in the new specs of the C++ language: lambdas, generics, templates... unnecessary. KISS.
... What? You don't want lambdas, but yet you complain about not having callbacks? You don't want generics or templates, so you apparently want to manually rewrite every single container because sometimes you need your list to store ints sometimes a list of floats and sometimes one of pointers?
The only part of "KISS" worth remembering is "stupid" because it's a worthless phrase. You don't _want_ a simple language. You want simple daily development. There _must_ be complexity somewhere. Either you are responsible for it (as in C) or the language helps you remove it (as in C++/Rust/D/etc.). e.g., the GC you asked for is _insanely_ complex to do well and any language with GC is far more complex than C, but it does heavily simplify the code you have to write when using the language. You can't "keep it simple." All you can do is move the complexity around, and preferably move it away from the user.
My understanding is that C++ is an impossible language to make good IDE features for (intellisense).. but it looks like its super easy to make intellisense for C# type languages.
It's not easy, no, but definitely possible. Heck, we can make powerful type-aware IDEs for dynamically-typed languages. Computational science is neat.
The preprocessor makes it kinda hard, but that's just as much of a pain in C as in C++. And you need some kind of tool like that, so either (a) you keep the preproc and all its warts, (b) you develop an integrated macro feature for the language and make it far more complex like Rust or D, or (c) you ignore the problem and require users to use some unofficial non-standardized third-party tool that will have even worse IDE integration.
I'm not looking to reinvent the wheel on any formats. For example, in our system we compile C code for an ARM platform which then produces an ELF file with DWARF debugging. We are only concerned with the language / IDE here.
Funny. The archaic nonsense of the C linkage model is actually one of the things I am _so_ ready for someone to replace.
... which modules do in quite a few languages that have them, e.g. C#'s Assemblies.
This is going to be your downfall.
You are incorrect in your understanding of why the C API (headers) is separate from its ABI (libraries).
I don't follow your argument at all. C++ is gaining modules. There's nothing incompatible with modules and the classic C linkage model.
Plus, there's all kinds of things you do about that linkage model to make it better. The static library approach used by every platform is infuriating, and in no way necessary.
You can have pre-compiled libraries that include metadata for compiling (again, see C# Assemblies). You can have platform-neutral pre-compiled libraries that are finalized at application compile time with no degradation in runtime speed nor compile speed over header-only or source-only libraries.
API and platform ABI and the C linkage model are _entirely_ separate things.
I even miss the separation when working with templated classes which I'm used to writing inline.
Nothing in the world stops you from separating them still. You don't have to put the method definitions inline, you can either put them at the end of the file or even in a separate file (e.g., a .inl file that gets included at the end of the .h file).
You can even take the approach used by folks like the BitSquid guys where the class template definition is completely sparated from the function template definitions in two separate headers; this lets your class headers include minimal type definitions while leaving all the complicated function machinery to headers only included by source files, which can cut down compile times quite a bit. (And incidentally, a proper module system would make this basically automatic.)
The C++ module systems in the works doesn't force you to remove the header setup either, btw. The idea of the proposed C++ module systems is that you can still write separate header and source files but then define a module that merges the public headers together into a fast metadata "module" that simplifies and speeds up compilation and linking for dependent modules.
It's a half-step to C#-style modules that leaves some problems and annoyances unsolved, but can be extended in the future after real-world implementation experience and in the mean time the C++ module system solves some of the most obnoxious problems of the C compilation model.
and I need to navigate 8 folders up, then 8 folders down in the "includes" folder to get the header and see it there, then have the two files open next to each other to make sense out of the whole thing.
You need better tools. I often jump between the header and related source in projects with equally crazy directory structures. VS+VAX makes it trivial. The only time I even need to pay attention to the directory structure is when I'm adding a new file.
