"Jacob Carlborg"  wrote in message news:ldtrf3$14t0$1@digitalmars.com... 

> On 2014-02-17 17:01, Kenji Hara wrote:
> > - modue private functions
> >    // Compiler can elide codegen for 'foo', if other declarations
> >    // in module a don't use it for runtime code.

> Private functions can be called from other modules via function pointers.

That would be a runtime use of 'foo', to get the function pointer.

On 2014-02-18 03:16, Daniel Murphy wrote:

> That would be a runtime use of 'foo', to get the function pointer.

Other modules can get the function pointer as well. Or perhaps that's what you're saying.

-- 
/Jacob Carlborg

On Friday, 14 February 2014 at 00:42:08 UTC, 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 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 :)

Added enhancement bugzilla because it's a great idea: https://d.puremagic.com/issues/show_bug.cgi?id=12270

Any news on this?

On Sunday, 13 July 2014 at 15:30:59 UTC, Trass3r wrote:
> Any news on this?

It's waiting on you or I to do the implementation and submit a pull request.  If it needs to be me, it'll probably be done sometime towards the end of 2016.  And that assumes the current desire to fossilize D doesn't prevent such changes from being accepted.

Mike

On Sunday, 13 July 2014 at 15:30:59 UTC, Trass3r wrote:
> Any news on this?

I haven't messed around with it since the winter and probably won't be able to for a while. (The current setup works well enough for me anyway...)

On Friday, 14 February 2014 at 00:42:08 UTC, 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:

I'm thinking about trying to implementing this.  There's some promising work in GDC[1] and DMD[2] related to reigning in TypeInfo, but it comes with compromises (e.g. not being able to use some of the convenient array-related functions and postblit).

[1] (GDC -fno-typeinfo) - https://github.com/D-Programming-GDC/GDC/pull/100
[2] (DMD Resolve TypeInfo variables after semantic) - https://github.com/D-Programming-Language/dmd/pull/4654

However, that work has helped me better understand what the compiler's doing and, with a little more study, I might be able to tackle this implementation.

> 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'm wondering if (2) and (3) need happen to keep the status quo.  typeid(T) would need to return TypeInfoImpl!(T), but if TypeInfoImpl!(T) is absent from the runtime, we could just throw a compiler error.  Currently if no TypeInfo is implemented in the runtime, errors happen, so we'd be no worse off.

For (3), is the trait really needed to keep the status quo? Again, the compiler would just throw an error if TypeInfoImpl!T.init() is not found.

As a result, the runtime would still need to have a TypeInfoImpl!(T) to get a build, but at least only what's actually used would need to be implemented.

Am I missing something?

Also, I think it solve the TypeInfo code bloat problem [3] when compiling with -ffunction-sections/-fdata-sections/--gc-sections.  The reason being that the compiler would no longer be "packing" the TypeInfo as alluded to in [4].

[3] (TypeInfo.name strings don't get put into separate sections when compiling with -fdata-sections) - http://bugzilla.gdcproject.org/show_bug.cgi?id=184
[4] (TypeInfo Packing) - http://forum.dlang.org/post/lfyehafdfrrktbwqemhu@forum.dlang.org

Mike