On Thu, Aug 08, 2019 at 10:04:14AM -0500, Segher Boessenkool wrote: > On Wed, Aug 07, 2019 at 02:58:12PM -0400, Arvind Sankar wrote: > > > > > code does is cheap. With "x->is_a (PLUS)", who knows what is > > > > > happening > > > That's not my point -- my point was that it is *obvious* the way things > > > are now, which is nice. > > > > My reply is pointing out that it is just as (non-)obvious with or > > without that inline function, if you want to use any of the helper > > macros. > > But that is not what you suggested, or at least not how I read it. > x->is_a (PLUS) > is not obviously cheap or simple at all, while > GET_CODE (x) == PLUS > obviously *is*. > > The former also isn't readable.
That's a matter of what style you prefer and it seems like no-one else shares my preference, and I accept that we're not going to make such a change. But there is really nothing more or less obvious about it. It's easy to go look at the code, as you probably once did when checking what GET_CODE or REG_P actually did, and is_a methods are expected to be lightweight. Regarding hiding things, consider that we just added LABEL_REF_P, which is for a comparison that happens less than half as often as PLUS in the codebase (and I think it was actually only used in one place). It was done presumably because the author/reviewers felt that LABEL_REF_P (x) is more readable than GET_CODE (x) == LABEL_REF, even if the latter might be ever so slightly more transparent as to what its doing than the former. > > Indirection is *the* evil in programming. Some would say that "All problems in computer science can be solved by another level of indirection" ;)
