Linker-hacking out the D runtime

[Mike via Digitalmars-d-announce]

On Monday, 19 December 2016 at 19:53:06 UTC, Iain Buclaw wrote:

> The compiler doesn't actually generate any code that peeks 
> inside TypeInfo.  It only generates the reference to the right 
> typeinfo to pass to library runtime functions -  or on request 
> via typeid().  It doesn't actually care about the data stored 
> inside.  And that's the angle I've taken when laying out the 
> actual data - if you provide the fields we want to populate, 
> then we'll populate them.  If you omit a few, then the compiler 
> won't bother with them.  Because at the end of the day, it's 
> druntime library that uses and makes sense of the TypeInfo data 
> provided.  The compile just says: "Well, this is as much as I'm 
> willing to tell you about the type."

Ok, that's interesting, but what if you don't want TypeInfo at 
all?  Can you omit the TypeInfo structure entirely from object.d? 
  Or perhaps you still need to declare it in object.d, but since 
the compiler doesn't find any fields to populate, it results in 
an empty struct?  I'd really hate to have to add empty 
TypeInfo_XXX classes to my object.d though.

I'm still wondering about what the programmer would see if they 
tried to do a dyamic cast (for example) and there was no (or an 
incomplete) TypeInfo in the runtime.

You see, when I started with D, I had a grand plan that I could 
create a product like Arduino. I would provide a PCB and an 
accompanying API/SDK to my customers, and they would do the 
programming.  I would have wanted them to have a polished 
experience when programming my product, so if they were doing 
something that wasn't supported by the platform, they would 
receive a friendly compiler message telling them so.

I thought that this would be possible if the compiler resolved 
druntime symbols at compile-time in the same way it does any 
other library: by reading .di header files.   If a symbol was not 
found, they would get a compiler error telling them so.  I could 
also add templates, static-ifs, and static asserts to the .di 
files for, not only generating highly optimized code, but also to 
notify the programmer with more helpful and precise compile-time 
messages.

I also envisioned products with very high resource constraints 
(like ARM Cortex-M0) without threading, but for high performance 
microcontrollers (like ARM Cortex-M4/7) I could leverage D's 
built-in understanding of thead as my RTOS.  Each product would, 
therefore, have very different druntime implementations.

I think what you're proposing here by tagging fields is certainly 
better than what we currently have, and would be desirable for 
other D users (especially those of late), but does it scale well 
if I want to deliver a polished programming experience (with 
optimized code generation) to my customers when my platform only 
has a subset of D's rich feature set?

Mike