[cfe-commits] [patch] TransformIterator (motivating use case in Clang)

[Douglas Gregor]

On May 15, 2012, at 3:44 PM, David Blaikie <dblaikie at gmail.com> wrote:

> On Tue, May 15, 2012 at 3:07 PM, Chandler Carruth <chandlerc at google.com> wrote:
>> On Tue, May 15, 2012 at 3:33 PM, David Blaikie <dblaikie at gmail.com> wrote:
>>> 
>>>> This seems like a lot of work and a disruptive change in API patterning,
>>>> and
>>>> I'm really not clear what problem it's trying to solve. My suspicion is
>>>> that
>>>> there isn't one other than a preference for references instead of
>>>> pointers.
>>> 
>>> Well the underlying problem was the inconsistency of the iterators in
>>> Decl/DeclBase. I wanted to rationalize their value/reference/pointer
>>> types so I could then extract the common filtering functionality out
>>> of filtered/specific_decl_iterator as a proof-of-concept for a general
>>> adapting/filtering iterator device which I could then re-use in my
>>> efforts to improve the CFG fidelity and -Wunreachable-code diagnostic.
>>> This particular path (generalizing the existing filtering iterators to
>>> a reusable adapter before reusing that in the new use case) was
>>> suggested by Ted Kremmenek & I was happy enough to have an excuse to
>>> tidy up some existing code.
>> 
>> 
>> Ok, but again, this is a disruptive change in API patterning. I don't think
>> the inconsistency you point out really justifies the churn without some more
>> compelling problem that it solves. That said, I'd be interested in Ted's
>> perspective here.
> 
> To be clear - I don't think Ted has a dog in this race (or hasn't
> expressed it, at least - though I wouldn't mind having a few more
> opinions on the issue since we've all got to work with the code base)
> - his involvement was just to say "yeah, we should probably factor out
> the common filtering iteration functionality first (before using it
> for the CFG)".
> 
>> I also don't see why its necessary to change the pointer / reference
>> semantics in order to factor out common iterator infrastructure, so I'm not
>> really clear why one is blocked on the other.
> 
> It's not - I just had to choose one way or the other, and without much
> in the way of feedback after a few weeks, it ended up tipping slightly
> towards value semantics so I carried along with that. Happy to change
> it over if that's the prevailing preference.


It makes sense to factor out the filtering-iterator functionality, but I'd rather not have to restyle the code base to do it.

	- Doug