Linker-hacking out the D runtime

[Iain Buclaw via Digitalmars-d-announce]

On 19 December 2016 at 01:36, Mike via Digitalmars-d-announce
<digitalmars-d-announce at puremagic.com> wrote:
> On Sunday, 18 December 2016 at 12:57:08 UTC, Iain Buclaw wrote:
>
>> As a response to my last message in that thread, the changes for classinfo
>> generation is now ready to go in master.
>
>
> Ok, I'll give it a test in the next week or so.
>
>> However I already have ideas for future implementation that is not so
>> naive when it comes to looking up fields to assign data.  How does a kind of
>> tagging system sound?
>>
>> i.e:
>>
>> class TypeInfo_Class
>> {
>>     @name
>>     string classname;
>>
>>     @init
>>     byte[] initializer;
>> }
>
>
> I'm assuming this idea addresses the issue with porting druntime and leaving
> some features unimplemented.  If I understand your intention, this looks
> akin to Rust's Lang Items feature
> (https://doc.rust-lang.org/book/lang-items.html).  Please correct me if I'm
> wrong.
>

Heh, I've never looked into Rust, so I didn't know that.  But in a
way, yes, it is quite similar.

> I'm not sure what you're envisioning here, so I'd like to hear more.  Would
> the user get compile-time errors if they used a D feature that required a
> druntime implementation, but the implementation did not exist?
>
> Mike
>

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

Iain