RFC: Move runtime hook definitions to a .di file in druntime

[Mike via D.gnu]

Hello,

In my continued, though stalled, effort to try and make minimal 
runtime for embedded systems, I've tried to find a way for users 
to know at compile-time if a feature of the runtime is supported 
or not, and more importantly, if they are explicitly or 
implicitly using an unsupported feature.

I'm not really in favor of adding a lot of compiler switches that 
create a new dialect of the language, though I'd take it if it 
were the only way.  I'd rather have druntime inform the compiler 
what is or isn't supported, and avoid compiler changes.

I've recently realized that druntime doesn't really have to be 
any different than other libraries: if a function isn't supported 
it simply isn't declared in the library's headers. If users make 
use of the undeclared function, explicitly or implicity, they get 
a compiler error, just like they would with any other library.  
Currently these library hooks are all declared in d-codegen.cc 
(https://github.com/D-Programming-GDC/GDC/blob/9a05197e64031b96fda72a4428e9bb9b7e37ff01/gcc/d/d-codegen.cc) 
and documented at http://wiki.dlang.org/Runtime_Hooks

So, I'm wondering if the compiler maintainers would entertain a 
change to the GDC that moved the runtime declarations (i.e. 
_d_newclass, _d_{whatever}) to a .di file in druntime.
* Compilation would automatically import this header.
* The compiler would throw an undefined identifier error if it 
needs to make a call to a runtime hook that isn't declared.
* The.di file could be object.di, since it seems to have already 
become the site for anything to be implicitly imported, but it 
doesn't have to be.

Of course there would have to be changes to the compiler to 
implement this idea, but I think it would be completely 
transparent to users.

Advantages:
* It will make it easier to implement a more polished minimal 
druntime, a "D as a better C", or some other variation of the 
language without having to resort to compiler changes.  Such a 
runtime has been asked for several times on these forums and even 
proposed by Walter.  This change won't eliminate calls for 
certain compiler switches, but it will provide developers with a 
few more tools to hopefully avoid them.

* It makes the language more consistent.  Runtime hooks could 
become less "special" to the language and the compiler, and can 
be treated just like any other library function: If the 
declaration doesn't exist, compiler error.

* Runtime hooks can be easily decorated with @deprecated or other 
attributes and enable several techniques to test language changes 
without having to rebuild the compiler.

Thanks for your thoughtful consideration,

Mike