<div class="gmail_quote">On Tue, May 15, 2012 at 3:33 PM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">> This seems like a lot of work and a disruptive change in API patterning, and<br>
> I'm really not clear what problem it's trying to solve. My suspicion is that<br>
> there isn't one other than a preference for references instead of pointers.<br>
<br>
</div>Well the underlying problem was the inconsistency of the iterators in<br>
Decl/DeclBase. I wanted to rationalize their value/reference/pointer<br>
types so I could then extract the common filtering functionality out<br>
of filtered/specific_decl_iterator as a proof-of-concept for a general<br>
adapting/filtering iterator device which I could then re-use in my<br>
efforts to improve the CFG fidelity and -Wunreachable-code diagnostic.<br>
This particular path (generalizing the existing filtering iterators to<br>
a reusable adapter before reusing that in the new use case) was<br>
suggested by Ted Kremmenek & I was happy enough to have an excuse to<br>
tidy up some existing code.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
</div>