Compiler patch for runtime reflection

[foobar]

Robert Jacques Wrote:

> On Sat, 22 Oct 2011 14:38:22 -0400, foobar <foo at bar.com> wrote:
> [snip]
> > IMHO, RTTI should be a built-in feature of the language.
> > 1) You need one global system agreed upon by all clients. Otherwise, you could end up in a situation where a single class has more than a single set of metadata used in several different scenarios.
> 
> Or a singleton class/struct. Yes, you should have a single global system, but nothing says that the system has to be the language. Library solution are also valid.

But couldn't someone implement a different singleton class? How would you make sure the system remains global? 

> 
> > 2) This information is required anyway in the run-time itself. This is a requirement for an accurate GC.
> 
> a) Not every user of D wants to use a GC. In fact, there's currently a push to remove / improve all the GC mandatory features of D to support ref-counting / manual memory usage.

Agreed and it is or should be made possible to not use the GC. However the default for D is GC. 

> b) RTTI is separate for GC BlockInfo. Yes, you could generate the  GC_BlockInfo from the RTTI, but doing so would be so inefficient that its not worth contemplating.

I'm not sure I follow. Are you discussing D's current GC implementation?
Generally speaking, an accurate GC AFAIK needs to have full type info. D's current GC does not have full type info and can have false positives hence it's a conservative GC. 

> 
> > 3) Other tools might use this info as well, debuggers, IDEs, etc.
> 
> Debuggers and IDEs already have all this information, and a lot more.
> 
> > 4) It's with the spirit of D design - make the common/safe case the default.
> 
> Since when has reflection ever been the common/safe case? .tupleof, despite being a god-send, is one of the most unsafe features of D. My personal impression of reflection is that it's one of those features that you only want 1% of the time, but if you don't have it, you're going to be pulling teeth to work around it.

That's why it should be able to turn off RTTI generation if it is not needed but it should be provided by default in order to prevent that pulling teeth sensation. It's safer to provide an off switch rather than an on switch. 

> 
> > As others mentioned, there should be a compiler switch to turn this off.
> > E.g. when developing for an embedded system where memory is scarce it makes sense to not generate RTTI. It also makes sense to disable the GC and preallocate the memory.
> 
> Isn't this statement and statement 4) in conflict with each other? Unlike a GC, turning off RTTI breaks everything that uses it.

where's the conflict? If my application does not use RTTI at all than the 'redundant' info can be removed. In fact, Thinking about it just know, It should be a link-time optimization - only if the linker did not see any usage of RTTI in the program, it'll remove the generated meta data.