I should preface this by saying I don't really have a good sense of how either BetterC or the D runtime work.

The recent BetterC thread made me wonder about TypeInfo in the D runtime. My (surface level) understanding is that this is what makes typeid work at run time.

I was looking through the C++ standard library headers and noticed <typeinfo> that has a typeid also. One difference with D is that it is opt-in as there is some cost using it.

I suppose I'm wondering what other differences there are. Could TypeInfo be made optional in D, like it is in C++?

On Thursday, 22 June 2017 at 14:30:31 UTC, jmh530 wrote:
> I was looking through the C++ standard library headers and noticed <typeinfo> that has a typeid also. One difference with D is that it is opt-in as there is some cost using it.

C++ also leaves most the properties for typeinfo to be implementation defined, meaning things like .name can just return an empty string. I believe the only thing the standard requires is consistent opEquals.

Additionally, C++ will only generate it for classes with at least one virtual member (the main use of it is dynamic casts, or substitutes thereof, and using those is often bad object oriented design anyway!)

> I suppose I'm wondering what other differences there are. Could TypeInfo be made optional in D, like it is in C++?

Much of it can, yes, and it can also be defined to offer less (or more! I'm actually a fan of runtime reflection) than it does now. There's an effort to convert typeinfo to be library templates instead of a compiler-provided blob like it is now.

But, even in C++, RTTI is necessary for dynamic casting... so how is D going to address that? I think it is necessary, but can prolly be quite minimal. I will think about it more later.

On Thursday, 22 June 2017 at 14:50:45 UTC, Adam D. Ruppe wrote:
> [snip]

I appreciate the reply.

Currently a lot of language features generate dependencies on TypeInfo, arguably more than needed, but this is changing.  Some examples are in this DConf 2017 talk:

https://www.youtube.com/watch?v=endKC3fDxqs

Also, the way the language is designed right now, all modules are responsible for containing TypeInfo instances for all their types, in case other modules *might* need them.  So, if you define a plain old data struct, for example, you get TypeInfo and its runtime dependencies.  This isn't a requirement, and Adam has just patched DMD to make -betterC leave out the TypeInfo.

> But, even in C++, RTTI is necessary for dynamic casting... so how is D going to address that? I think it is necessary, but can prolly be quite minimal. I will think about it more later.

Does it matter?  C++ programmers already accept that RTTI is needed for certain dynamic features.

On Friday, 23 June 2017 at 00:41:11 UTC, sarn wrote:
> Does it matter?  C++ programmers already accept that RTTI is needed for certain dynamic features.

Yes, it is necessary, but how much? Can we do it with implicitly generated library code?

I'm pretty sure the answer is "not much" and "yes", but I still need to ponder the details. I think the typeinfo for a class good enough for dynamic cast could be about half the size we have now.

Though like I said, a lot of the stuff we have now is cool stuff, so I don't want to miss it entirely, it could be behind another pointer.

On Friday, 23 June 2017 at 02:14:08 UTC, Adam D. Ruppe wrote:

> Yes, it is necessary, but how much? Can we do it with implicitly generated library code?
>
> I'm pretty sure the answer is "not much" and "yes", but I still need to ponder the details. I think the typeinfo for a class good enough for dynamic cast could be about half the size we have now.
>
> Though like I said, a lot of the stuff we have now is cool stuff, so I don't want to miss it entirely, it could be behind another pointer.

I'm not sure what you have in mind, but TypeInfo in itself is not bad and has some very useful features even for resource constrained devices and other niche domains.

The problem is that the current compiler-runtime requires it to exist just to get a build, even though it's not being used in the source code (implicitly or otherwise) and has no chance of ever being executed or referenced in the resulting binary.

Also, TypeInfo has been overused in the compiler-runtime implementation.  For example:  http://forum.dlang.org/post/mrmv61$230i$1@digitalmars.com

The compiler should be able to generate the object code in a way that allows the linker to discard it, if it can't find anything that uses it.  I think LTO has made such features even more intelligent.

I'd like to see 3 improvements:
1.  The compiler doesn't require TypeInfo to be implemented in the runtime if the user's code will never make use of it.
2.  If TypeInfo is implemented in the runtime, the compiler generates the object code in a way that permits the linker to discard it if it can't find a link to it.
3.  If only one item is needed out of TypeInfo, pass a reference to that instead of the entire TypeInfo object in the compiler-runtime implementation, so implementations can be made more granular.  Or perhaps TypeInfo should be broken up into a few smaller types.

Mike

On Friday, 23 June 2017 at 02:49:27 UTC, Mike wrote:
> I'm not sure what you have in mind, but TypeInfo in itself is not bad and has some very useful features even for resource constrained devices and other niche domains.

Yeah, I agree with you.

My approaches are right now for -betterC to be a filthy hack to get it working quick, and I still have a bunch of ways I want to improve the implementation and compiler interface in the main, non-hack-switch too.

My wrist is sore today though so I gotta take a break... but I think you and I have the same goals in mind.

On Friday, 23 June 2017 at 04:03:04 UTC, Adam D. Ruppe wrote:
> On Friday, 23 June 2017 at 02:49:27 UTC, Mike wrote:
> My approaches are right now for -betterC to be a filthy hack to get it working quick, and I still have a bunch of ways I want to improve the implementation and compiler interface in the main, non-hack-switch too.

Hi! I'm working on a small custom standard library (just because) and I cannot figure out how get object.d smaller. It's a huge mess, with everything defined inside. Could you pass along the 'filthy hack'? I need some way to get object.d to pass through without druntime or phobos, whatsoever. I am importing small modules and functions that I find necessary, but I am not using TypeInfo at all and hope to get rid of the problem.