On 20 December 2016 at 12:24, Mike via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
> On Monday, 19 December 2016 at 19:53:06 UTC, Iain Buclaw wrote:
>
>> The compiler doesn't actually generate any code that peeks inside
>> TypeInfo.  It only generates the reference to the right typeinfo to pass to
>> library runtime functions -  or on request via typeid().  It doesn't
>> actually care about the data stored inside.  And that's the angle I've taken
>> when laying out the actual data - if you provide the fields we want to
>> populate, then we'll populate them.  If you omit a few, then the compiler
>> won't bother with them.  Because at the end of the day, it's druntime
>> library that uses and makes sense of the TypeInfo data provided.  The
>> compile just says: "Well, this is as much as I'm willing to tell you about
>> the type."
>
>
> Ok, that's interesting, but what if you don't want TypeInfo at all?  Can you omit the TypeInfo structure entirely from object.d?  Or perhaps you still need to declare it in object.d, but since the compiler doesn't find any fields to populate, it results in an empty struct?  I'd really hate to have to add empty TypeInfo_XXX classes to my object.d though.
>

Yeah, there are two logical steps that need ratifying.

1) -fno-rtti should be a flag that is honoured by the compiler. 2) Runtime functions that "lower" to a C function call should not generate RTTI if all information about the type is known at compile-time.

There are ideas floating around to improve [2], but for the time being however, marking all functions as @nogc catches almost all cases where this happens.

On Sunday, 8 January 2017 at 22:14:36 UTC, Iain Buclaw wrote:

> 1) -fno-rtti should be a flag that is honoured by the compiler.

The more I think about it the more I dislike the whole idea of -fno-rtti.  All I've ever wanted from the D compiler is to not put code in my binary that has not chance of ever being used.  Or, to generate it in a way that can be garbage collected by the linker.

If that dream came true, I could avoid RTTI by simply avoiding any feature that needed it (REALLY needed it!) and -fno-rtti would be of no value, except to enforce policy.

On Monday, 9 January 2017 at 13:42:01 UTC, Mike wrote:
> On Sunday, 8 January 2017 at 22:14:36 UTC, Iain Buclaw wrote:
>
>> 1) -fno-rtti should be a flag that is honoured by the compiler.
>
> The more I think about it the more I dislike the whole idea of -fno-rtti.  All I've ever wanted from the D compiler is to not put code in my binary that has not chance of ever being used.  Or, to generate it in a way that can be garbage collected by the linker.

I've actually come to the same conclusion.  Different combinations of compiler flags for different codebases is just a recipe for pain.  We already have things like nothrow, and I'm pretty sure we can solve at least most of the problem just by exploiting language features to do what you said.