[PATCH 0/6] Conversion of gimple types to C++ inheritance (v3)

[Jeff Law]

On 11/06/13 06:23, Joseph S. Myers wrote:
> On Wed, 6 Nov 2013, Jakub Jelinek wrote:
>
>> On Wed, Nov 06, 2013 at 12:31:00PM +0100, Richard Biener wrote:
>>>> Maybe we need to revisit it? As one of those who were not in favour of
>>>> the C++ move, can I ask you guys to step back for a moment and think
>>>> about - what do all of these changes buy us, exactly? Imagine the state
>>>> at the end, where everything is converted and supposedly the temporary
>>>> ugliness is gone, what have we gained over the code as it is now?
>>>
>>> as_a gains us less runtime checking and more static type checking
>>> which is good.
>>
>> But that really affects --enable-checking=yes builds (and only cases where
>> things aren't inlined).  If the price for that is uglier and less readable
>> code, then the price is just too high.
>
> I see static type checking as being about preventing certain sorts of bugs
> getting in the compiler at all, rather than about saving time on runtime
> checks for --enable-checking=yes.
Amen!  When I've described RTL & trees to other folks in the business 
that work(ed) on other compilers, most gasped in horror.  Doubly so when 
I did this prior to the introduction of the tree/rtl checking systems.


>
> I don't have advice on the gimple case.  But certainly trees and RTL could
> both do with more static typing.  There, I'm thinking of different types
> of objects (types, expressions, ...) logically being completely separate
> static types, not inheriting from a common "tree" base class at all.  But
> if inheritance and as_a can be used as intermediate steps to allow an
> incremental transition to completely separate static types, where
> otherwise the whole source tree would need converting at once, that seems
> reasonable to me. (I have no comments about what things should look like
> in cases where completely separate static types don't make sense but there
> is still some sort of inheritance structure.)
I hadn't really thought of it that way -- specifically that when we're 
done we don't necessarily need to have decls, types, expressions 
inheriting from a common tree base class.  I must say, I like it as a 
guiding principle.

Jeff