> Also, we already have an Apple/Next non-standard C extension (objective-C). I don't think we want anything else added without proper standardisation regardless of the motivation. I'd rather they forked the language.

This is confusing. Surely Objective-C, which adds a hell of a lot that C does not address and many syntax and runtime changes to support it, would fall under the definition of "fork of the language", rather as C++ does, rather than simply a "non-standard C extension" (surely that description better applies to the many GNU C extensions in GCC?).

Re: "adding things without proper standardization", the role of standards committees is to reach consensus among vendors so that they can standardize non-standard extensions that they have variously implemented and tested in the real world first. To argue for the opposite, that the vendors must do nothing until the committee hands down the One True Way from On High, untested outside of their heads, is the height of Design By Committee.

> Surely Objective-C, which adds a hell of a lot that C does not address and many syntax and runtime changes to support it, would fall under the definition of "fork of the language"

It's not even a fork, it's a different language source-compatible with C. It has its own semantics, its own syntax and its own runtime.

> Well Objective C was a preprocessor extension as this proposal is so it's one and the same. Both are extensions.

This is daft. Objective-C has been implemented using a full-fledged compiler for decades. Is C++ "just an extension to C" because it was once a pre-processor on top of C? Is Common Lisp "an extension to C" because ECL transforms it into C?

Utter lunacy.

> Yes we all know where vendors that do that got us

Yes; they got us tried and tested ways of implementing things like gradients, so that the standards body had something in the real world to base a successful standard off of. The alternative gets us things like C++98's export templates: unimplementable garbage that no vendors could support because they were invented on paper and any attempt to actually build them in the real world caused more problems than they solved.

And just so we're clear what's going on here:

The linked slides are about LLVM's implementation of Daveed Vandevoorde's proposal to the C++ committee (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n334...). The C++ Standards Committee held off on adopting that proposal for C++11 because there were no implementations of it, and asked that vendors try implementing it, adapting it as necessary to make it feasible, and provide feedback so that informed decisions based on experience could be made in the final draft of C++17.

Let me repeat that: LLVM is doing exactly what the standards committee asked them to do.

Thanks for linking to Daveed Vandevoorde's proposal. I had no idea that he had originated this concept, else I would have worded the title differently.

I guess you haven't tried to compile a big project like WebKit to experience the pain of importing large header files.

Well-defined modules, if standardized, would be a huge boost to C and C++ compilation speed. Remember the proposal does not take anything away, you can always use #include, but adds a new method for those wanting to take advantage of it. Why the resistance there?

Doug Gregor, the author of this proposal, is the chair of the modules study group of the C++ standards committee (source: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n338...). And this proposal looks very similar to the C++ modules proposal by Daveed Vandevoorde http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n334...

So it looks like Apple is working towards making this a standard, not a non-standard extension.

WRT compiler overhead, this is an asymptotic improvement, not just a constant factor. If this can get my 30-second to 20-minute compiles (depending on what's changed since the last make) down to the compile-duration range of Go (which uses this kind of dependency management for compiler performance reasons) that completely changes the workflows that are possible.

But yeah - the standardisation issue is worrying, although at least it looks like they've thought about the issue with their transitional proposal.

Compile time is usually fine if you build your code so that dependencies are simple as intermediate .o files are only built in dependency chains. Link time is much higher on larger projects, which this still fails to solve.

Knowing your shit gets you further than language changes here.

For ref, I've been writing c since 1986 and I've seen proposals like this come and go lots and every one doesn't end up with an improvement.

I haven't used C++ recently, and never in truly large projects, but what I do remember is that that "build your code so that dependencies are simple" is not something you get for free, certainly not with C++.

I also think that Apple wants every compilation speed improvement it can find, so that it can improve syntax coloring and error highlighting in (almost) real time while you are editing.

Finally, I don't think this really is a proposal. Apple shows its intent earlier than they did with WebKit, but read that last slide: "clang implementation underway".

I expect they will listen to feedback and change this if people propose real improvements, but I think it is a given that this will be in clang soon, and also that it will be used in clang, LLVM, and WebKit. From there, chances are it will spread, either via tools that use WebKit or LLVM, or because of superior compilation speed.

How soon that 'soon' will be, I don't know. Implementation may not be as simple as it looks.

I've used Oberon, which has a module system quite similar to this, quite heavily, and the way to diminish link time is to not link, instead use dynamic loading: leaf modules are loadable and unloadable, nonleaf modules can be made leaf by unloading all their descendants. Gives you the possibility for immediacy/flow, that a good REPL does. For many cases, you get edit/compile/run cycles measured in (often single-digit) seconds.

Agree with this completely.