https://issues.dlang.org/show_bug.cgi?id=16683

Andrei Alexandrescu <andrei@erdani.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrei@erdani.com

--- Comment #1 from Andrei Alexandrescu <andrei@erdani.com> ---
To clarify, we want to lower occurrences of typeid(Xyz), where Xyz is a type,
to

.typeidImpl!(Xyz)()

Then we implement that function in object.d. For now we may leave other uses, such as typeid(5), unchanged.

The advantage of this is that we shift implementation from the compiler internals to the core runtime, which gives us more leeway. Also, the new function being a template, it's not instantiated if not used which saves on data. (Presumably the TypeInfo objects would be function-static.)

--

https://issues.dlang.org/show_bug.cgi?id=16683

--- Comment #2 from Andrei Alexandrescu <andrei@erdani.com> ---
See also http://forum.dlang.org/post/o0kdnp$2i2t$1@digitalmars.com

--

https://issues.dlang.org/show_bug.cgi?id=16683

ZombineDev <petar.p.kirov@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |petar.p.kirov@gmail.com

--

https://issues.dlang.org/show_bug.cgi?id=16683

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com

--- Comment #3 from Walter Bright <bugzilla@digitalmars.com> ---
In order to get this to work, it would have to have a druntime template that generates the following info for the typeid:

               {
                    void **vptr;
                    monitor_t monitor;
                    byte[] m_init;              // static initialization data
                    string name;                // class name
                    void*[] vtbl;
                    Interface[] interfaces;
                    ClassInfo base;             // base class
                    void* destructor;
                    void function(Object) classInvariant;   // class invariant
                    ClassFlags m_flags;
                    void* deallocator;
                    OffsetTypeInfo[] offTi;
                    void function(Object) defaultConstructor;
                    //const(MemberInfo[]) function(string) xgetMembers;   //
module getMembers() function
                    immutable(void)* m_RTInfo;
                    //TypeInfo typeinfo;
               }

which is what the compiler does in the toobj.d module in the visit(ClassDeclaration cd) function. Doing this is fairly complex, depending on how far one wishes to go with it - for example, preparing the initializer for the .vtbl field is quite daunting. Perhaps have the compiler provide that via a __traits? That would relieve some of the complexity of doing this. Or maybe have the compiler still generate this data, but only to make it accessible via __traits() and then have the druntime template cherry pick it as necessary?

--

https://issues.dlang.org/show_bug.cgi?id=16683

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P3

--

https://issues.dlang.org/show_bug.cgi?id=16683

--- Comment #4 from dlangBugzillaToGithub <robert.schadek@posteo.de> ---
THIS ISSUE HAS BEEN MOVED TO GITHUB

https://github.com/dlang/dmd/issues/17337

DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB

--