[PATCH 1/2] add staticly checked label_nuses accessors

[Jeff Law]

On 09/05/14 16:38, Trevor Saunders wrote:
>
> So, in this case it seems to me you basically have two options
>
> A. change the macro to an inline function, and fix up all the callers to
> pass the right type.  Then rebase that into some sort of reasonable
> patch series.
>
> b. add a function with a different name and convert users piece meal,
> and then remove the old macro (I guess you can then rename the new
> function to the old macro if you like).
>
> of those I prefer b because it means you can convert call sites one at a
> time and its easy to know which have been delt with.
My worry with piecemeal is obviously an incomplete transition.  While we 
have that to some extent with David's patches, we don't generally have 
two ways to get at the same hunk of data.




>
> I also do think the advantages of using members outways the cost.
I don't think it's always the case, but my general preference will be to 
go to member functions.


>
> For one thing functions with all caps names are just weird.  I think the
> more important reason though is that it will help make rtx_insn be a
> separate class sometime in the far future, since at some point we can
> make its inheritance from rtx_def protected to chase down things that
> try to convert from rtx_insn to rtx.  There's also the argument that its
> inconsistant to have some things be members and others be functions.
Yes, the all caps is weird.  There was a time when the all caps 
designated that we were using a macro and it was expected to be very 
efficient.  When calling a function we were supposed to use lowercase to 
signify the likely high overhead.

I'd tend to lean towards #1.  If we want to convert to methods, I think 
that can be a follow-up.  Type safety is my focus right now, not pushing 
towards member functions.

Jeff