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 :)

But that would mean that you have to pull the implementation of casts and other features that rely on TypeInfo right now into the library too. Do you really think this such a good idea? My biggest concern with this is, that when TypeInfo is pulled into phobos, the implementation of TypeInfo is going to depend on _all_ phobos modules, making at lot harder to use D without phobos unless you want to rewrite the entire TypeInfo and all features depending on it.

On Friday, 14 February 2014 at 09:09:42 UTC, Benjamin Thaut wrote:
> But that would mean that you have to pull the implementation of casts and other features that rely on TypeInfo right now into the library too. Do you really think this such a good idea? My biggest concern with this is, that when TypeInfo is pulled into phobos, the implementation of TypeInfo is going to depend on _all_ phobos modules, making at lot harder to use D without phobos unless you want to rewrite the entire TypeInfo and all features depending on it.

I think Adam would have to clarify what he meant by "the library".  I'd like all the TypeInfo stuff in the runtime, not phobos.  According to a conversation I had with Iain Buclaw [1], the TypeInfo implementations are broken into two parts:  There's the TypeInfo implementations in object.d/di and then there's the TypeInfo implementations in D runtime's src/rt/typeinfo folder [2].

I don't understand why the two are separated.  Iain just said the ones in object.d "are required to be known at compile time for certain operations."

I'm too much of a D novice to understand the implications of Adam's proposal, but if it's feasible, I think it would be be quite useful to those porting D to more limited platforms like I am.  Currently I'm fooling the compiler with silly things like...

class TypeInfo_Class : TypeInfo
{
    ubyte[68] ignore;
}

... and that's a dirty hack if I ever saw one.

The runtime might be a good place for it given the consequences you've just articulated.  The bottom line, I think, is to get it out of the compiler.

Mike

[1] http://forum.dlang.org/post/mailman.211.1389183225.15871.digitalmars-d@puremagic.com
[2] https://github.com/D-Programming-Language/druntime/tree/master/src/rt/typeinfo

On Friday, 14 February 2014 at 09:09:42 UTC, Benjamin Thaut wrote:
> But that would mean that you have to pull the implementation of casts and other features that rely on TypeInfo right now into the library too.

They already are: druntime/src/rt/cast_.d I wouldn't change that, I'm more thinking about changing rt/typeinfo/*.d from being hand-written to auto generated by a template and moving the object size and layout from the compiler (see verifyStructSize in dmd) to the druntime code too.

No phobos here, that would definitely be a bad idea.

> making at lot harder to use D without phobos unless you want to rewrite the entire TypeInfo and all features depending on it.

Right now, if you try to use D without druntime, it will complain about missing typeinfos and force you to create the classes with a particular size. Much of it can be auto generated by templates now (which gives a lot of cool flexibility btw), but you are still locked into the compiler's fairly strict layout. I want to open up some flexibility.

On Friday, 14 February 2014 at 11:26:42 UTC, Mike wrote:
> I think Adam would have to clarify what he meant by "the library".

You got it.

On 14.02.2014 01:42, Adam D. Ruppe wrote:
> 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 like this idea (I remember I had this also as a suggestion on my slides for dconf2013). This is just taking the RTInfo template generation a step further, yet coming with the same problems. See this pull request for a (probably incomplete) list of places I found where type info generation is triggered from the glue code, and not during semantic analysis:

https://github.com/D-Programming-Language/dmd/pull/2480

The only drawback I see is that it makes compilation a bit slower and pollutes object files with code just executed during CTFE. Unfortunately this often also ends up in the executable because it is referenced by some data not in COMDATs.

On 2014-02-14 01:42, Adam D. Ruppe wrote:

> I think the others are already possible:
>
> string TypeInfoImpl!T.toString() { return T.stringof; }
> interface TypeInfo {} /* TypeInfoImpl(T) : TypeInfo */

Currently what .stringof evaluates to and the format of it is not specified and should not be relied. I assume the current typeid(T).toString is reliable.

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

What about the rest of the fields, in ClassInfo, for example? Implement with traits? I'm thinking of "classInvariant", "m_flags", "deallocator", "defaultConstructor" and so on.

-- 
/Jacob Carlborg

Am 14.02.2014 16:32, schrieb Adam D. Ruppe:
> On Friday, 14 February 2014 at 09:09:42 UTC, Benjamin Thaut wrote:
>> But that would mean that you have to pull the implementation of casts
>> and other features that rely on TypeInfo right now into the library too.
>
> They already are: druntime/src/rt/cast_.d I wouldn't change that, I'm
> more thinking about changing rt/typeinfo/*.d from being hand-written to
> auto generated by a template and moving the object size and layout from
> the compiler (see verifyStructSize in dmd) to the druntime code too.
>
> No phobos here, that would definitely be a bad idea.
>
>> making at lot harder to use D without phobos unless you want to
>> rewrite the entire TypeInfo and all features depending on it.
>
> Right now, if you try to use D without druntime, it will complain about
> missing typeinfos and force you to create the classes with a particular
> size. Much of it can be auto generated by templates now (which gives a
> lot of cool flexibility btw), but you are still locked into the
> compiler's fairly strict layout. I want to open up some flexibility.

Ok, I misunderstood you then. Moving TypeInfo generation to druntime would actually be a good idea. Ocasionally I wanted to extend TypeInfo for various use cases.

I said using D without phobos, I never said using D without druntime. Thats a difference.

On 2/13/2014 4:42 PM, Adam D. Ruppe wrote:
> 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!

It's a good idea worth exploring.

On Sunday, 16 February 2014 at 20:19:13 UTC, Walter Bright wrote:
> It's a good idea worth exploring.

Walter, I'm glad you voiced your opinion on this.

In my opinion, this should be a prerequisite to the minimalD ideas that are currently being discussed.  While I don't want to ask you to step away from more high value tasks that benefit the larger community, I'm wondering...would you be willing to mentor this change and help the community do the implementation?

I don't have the skills to implement this (yet), so is there anyone else out there that I could support (bribe) to make this change happen?

Mike