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

[Mike via D.gnu]

On Saturday, 11 October 2014 at 08:15:55 UTC, Iain Buclaw via 
D.gnu wrote:

>> 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.


> Seems reasonable, and though such a thing may be advantageous 
> on some
> levels,I believe in the fairness of balance there should be a 
> fair
> counter argument before drawing up a conclusion.
>
> Disadvantages:
>
> * The runtime hooks in the *.di file must still match the 
> signature
> the compiler expects it to be.  In one essence this doesn't 
> loosen the
> separation between compiler and runtime, it instead makes it 
> more
> fragile if someone get's their forked version of the runtime 
> hooks
> wrong.
>
> * Possibly extra semantic processing during the mid-flight of 
> codegen
> may be required to verify that the parameters the compiler 
> generates
> to pass match the function declaration when generating the call
> expression.  Ideally the backend should not have to do this.
>
> * GDC applies certain special attributes to some runtime 
> functions
> that can't be applied in normal D code.  Currently only the 
> following
> associations apply:
>  1. _d_assert and friends are marked as volatile because they 
> will
> never return normally.
>  2. _d_allocmemory is marked as malloc, to allow the compile to
> optimise more aggressively around inlined functions that create 
> a
> closure (this can save some needless allocation calls).
>
>
> I'm not knocking this idea though.
>
> Iain.

I feel silly for what I'm about to ask, but I'm getting 
desperate...

If there truly is merit to this idea, would anyone be willing to 
mentor me through the implementation? I've tried to get a picture 
in my mind on how the differnt pieces would come together, but 
I'm not getting it by reading the source code.  How would you 
approach this? Can you formulate it into a list of tasks to 
perform?

Mike