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
