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?


Reply via email to