• jmh530 (10/10) Jun 22 2017 I should preface this by saying I don't really have a good sense
• Adam D. Ruppe (16/21) Jun 22 2017 C++ also leaves most the properties for typeinfo to be
• jmh530 (2/3) Jun 22 2017 I appreciate the reply.
• sarn (12/15) Jun 22 2017 Currently a lot of language features generate dependencies on
• Adam D. Ruppe (9/11) Jun 22 2017 Yes, it is necessary, but how much? Can we do it with implicitly
• Mike (27/36) Jun 22 2017 I'm not sure what you have in mind, but TypeInfo in itself is not
• Adam D. Ruppe (8/11) Jun 22 2017 Yeah, I agree with you.
• ARaspiK (8/13) Jul 10 2018 Hi! I'm working on a small custom standard library (just because)

jmh530 <john.michael.hall gmail.com> writes:

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++?

Adam D. Ruppe <destructionator gmail.com> writes:

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.

jmh530 <john.michael.hall gmail.com> writes:

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

I appreciate the reply.

sarn <sarn theartofmachinery.com> writes:

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.

Adam D. Ruppe <destructionator gmail.com> writes:

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.

Mike <none none.com> writes:

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

Adam D. Ruppe <destructionator gmail.com> writes:

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.

ARaspiK <araspik protonmail.com> writes:

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.