[cfe-commits] [possible patches] specific/filtered_decl_iterator aren't iterators

[David Blaikie]

On Sun, Apr 29, 2012 at 5:43 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> On Sun, Apr 29, 2012 at 5:12 PM, David Blaikie <dblaikie at gmail.com> wrote:
>>
>> [oops, meant to move this to cfe-commits in the process]
>>
>> On Sun, Apr 29, 2012 at 5:11 PM, David Blaikie <dblaikie at gmail.com> wrote:
>> > Well, in the interests of demonstration I've implemented a basic pass
>> > at both options. I wouldn't mind someone signing off on one of these
>> > two - the current state isn't really viable so far as I can see, so
>> > it's one or the other. I personally tend towards the "reference"
>> > version (& in the ref_further you can see I got bored & pushed
>> > references further down through a few other APIs that don't need the
>> > optionality (nullness) of pointers anyway) but I'm not terribly fussed
>> > either way.
>
>
> specific_iter_ref.diff LGTM.

Thanks Richard - committed as r155808.

> I'm less convinced by specific_iter_ref_further.diff: it introduces a lot of
> churn into the svn history, and since we don't consistently treat pointer
> arguments as nullable, I'm not sure it buys us much.

Fair - it's a pity, though. Though I don't think consistency is
necessary for value here - reference arguments are clearly
non-nullable by design, pointer arguments might be either in the
current codebase. So we don't need to always use pointers for
optionality to gain something by using references in even a handful of
places. In those places it'll be clear something is non-null, and in
the pointer cases it could be either, but it's at least reduced
uncertainty, even if it hasn't removed it.

Revision & blame churn is a cost - I'm not sure how to quantify it, though.

- David