Compiler patch for runtime reflection

[Robert Jacques]

On Sat, 22 Oct 2011 17:37:40 -0400, foobar <foo at bar.com> wrote:

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

Sure.

> How would you make sure the system remains global?

You put it in Phobos.

>>
>> > 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.

But nothing depends on the GC. Things would depend on RTTI.

>> 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.

The type info used for the GC and the type info for reflection are two very different things. Saying that having one implies the other is fallacious.

[snip]

>> > 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.

So, let me get this right. If 99% of the time you don't want something, and 1% of the time you do, it's your opinion is that the default should be the 1% case? Because it's safer? By the way, I'm pretty sure we have very different meaning of the word 'safe' here.

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

Common features are by their very definition, pervasive and thus not disable-able. Hence, your statement 4 and 5 are in conflict with each other. Only one may be true.

> If my application does not use RTTI at all than the 'redundant' info can be removed.

Generally speaking, no, actually it can't. I guess some form of LTO might be able to do this, but we are getting into the realm of requiring `a sufficiently smart compiler`.

> 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.

Umm, no. That's not what LTO means. LTO means that instead of having a compiler and a linker, you just have the compiler-front end and the compiler back-end. And then, maybe, it can not generate the meta-data in the first place. Because the compiler never is going to solve the 'was this ever accessed' problem.

Besides, D specifically is designed to allow 3rd party object files, obfuscation, etc, which really isn't compatible with LTO.