On May 15, 2012, at 3:44 PM, David Blaikie <[email protected]> wrote:
> On Tue, May 15, 2012 at 3:07 PM, Chandler Carruth <[email protected]> > wrote: >> On Tue, May 15, 2012 at 3:33 PM, David Blaikie <[email protected]> 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 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
