On Sat, 22 Oct 2011 14:38:22 -0400, foobar <f...@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.
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. 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.
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.
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.
