www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 12270] New: Move TypeInfo to the D Runtime

https://d.puremagic.com/issues/show_bug.cgi?id=12270

           Summary: Move TypeInfo to the D Runtime
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: slavo5150 yahoo.com


--- Comment #0 from Mike Franklin <slavo5150 yahoo.com> 2014-02-26 17:06:51 PST
---
Adam D Ruppe's proposal originally posted here:
http://forum.dlang.org/post/eiwalbqlbkipdrmsrfoh forum.dlang.org

*****************************************
I'd like to see typeinfo moved completely to the library. The 
language would then not depend on it directly. The point of this 
thread is to see how practical it is. Here's the changes I have 
in mind:

1) Stop automatic generation of TypeInfo.

2) typeid(T) in the language now returns a static instance of 
TypeInfoImpl!T. The vtbl entry in a class also points to this. If 
the library doesn't implement TypeInfoImpl(T), these return null.

3) Add __traits(classInitializer, Class) which returns what we 
have today through typeid(Class).init. (This would be used to 
make init in the library implementation)


I think the others are already possible:

string TypeInfoImpl!T.toString() { return T.stringof; }
interface TypeInfo {} /* TypeInfoImpl(T) : TypeInfo */

// ElementType used for illustration only, no need to depend on 
phobos since we can do this with an is expression too. that's 
just harder to read/write lol

TypeInfo TypeInfoImpl!T.next() { return typeid(ElementType!T); }

Interfaces and parent class can also be done with traits today, 
so we can auto-generate the with a template too.

And so on, look at druntime's typeinfos now, most of it is just 
doing a bunch of casts of the same code - easily templated.

If I'm not missing anything, these three changes would let us 
completely define (or not define) type info in the library 
without breaking anything we have now!

Functions that depend on typeinfo can be generated the same way 
as they are now, though of course, I'd also enjoy moving more of 
those things (arrays, etc.) to be templates too :)

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 26 2014