[faresahmed]

IMO separation of interface and implementation is one of the "good" things about C/C++ (I used to be confused about it when starting out), it gives you a good overview of a piece of code and how it is supposed to be used. In other languages with no such "feature", you'll have to scroll hundreds of lines of implementation details you don't care about to understand the interface. You say this as a possible solution:

> You can still use header files if you want to, they’re just no longer strictly necessary. You’re free to put struct definitions and function prototypes into a header file if you’d like.

But is it really? not enforcing header files across the codebase means that you'll definitely end up with some inconsistency sooner or later that will be hard to deal with.

> The order that you include the source files in all.c matters. In the above example, bar.c had to be included before foo.c because foo.c used a struct and function that was defined in bar.c.

This is just additional overhead that you don't need while implementing something new.

And in general, this goes against how normally C/C++ codebases are structured, I'm sure I'll be hella confused about a file called `all.c`.

[tyleo]

I worked at a company which had a Unity builded codebase. The company had actually branched the codebase for two separate products. One of the products kept the .h/.cpp build running in CI in addition to the Unity build, the other product only used the Unity build.

My experience was that there was decent benefit to keeping the .h/.cpp build running. Most 'normal' C++ tools and IDEs are not going to assume you are using a Unity build and tend to choke on it. Even though we never really shipped anything from the non-Unity build, having it around was useful for avoiding 'phantom' errors in the IDE and having static analysis tools work properly.