Mark RTTI methods as const / pure, so compiler could optimize subsequent calls, if necessary.

[asl]

No description provided.

[asl]

Recently I noticed that compiler was unable to optimize multiple calls to ->to<T>() and ->is<T>() on the same node. It turns out that due to virtual calls it is in general takes a conservative approach.

With this PR we add pure / const attributes to corresponding typeid / isA and to implementation functions to correctly represent semantics.

Note that typeid and isA are const since they do not access any global state, their return values depend only on arguments. toImpl is pure as its return value depends on the global state, but only via this argument.

[asl]

@vlstill Will you please take a look when you will have a chance?

[vlstill]

Looks mostly good to me.

• Should the annotations be also on the base methods in the RTTI::Base? I think that would make sense.
• Can you add a comment why these attributes are helpful?

[asl]

• Should the annotations be also on the base methods in the RTTI::Base? I think that would make sense.

These methods are pure virtual there as they are part of interface. They technically might be non pure / const as this is essentially an implementation detail (though I doubt anyone would implement things differently, but still the interface allows this :) ) Note that RTTI::Base is never used as-is, it is expected that it is always a base class, so no declarations are visible there.

Other methods are non-virtual there and fully inlineable ad therefore there is no need for annotation there.

[asl]

Comments were added

[vlstill]

• Should the annotations be also on the base methods in the RTTI::Base? I think that would make sense.

These methods are pure virtual there as they are part of interface. They technically might be non pure / const as this is essentially an implementation detail (though I doubt anyone would implement things differently, but still the interface allows this :) )

Yes, although the same is true for the implementation methods, as they can still be (in theory) overridden by non-pure/non-const versions, although that would probably violate some (at least implicit) requirements for RTTI methods. Therefore having the [[const]]/[[pure]] in the base "interface" might be a bit stronger declaration of the intend these functions should behave that way.

Note that RTTI::Base is never used as-is, it is expected that it is always a base class, so no declarations are visible there.

True, therefore from the compilator standpoint it probably doesn't matter. It is really hard to find any resources on handling [[const]]/[[pure]] on virtual functions though.

Other methods are non-virtual there and fully inlineable ad therefore there is no need for annotation there.

Yes, I had only the virtual methods in mind.

---

Overall, I am OK with having the attributes as is.