On Sun, Apr 29, 2012 at 5:43 PM, Richard Smith <[email protected]> wrote: > On Sun, Apr 29, 2012 at 5:12 PM, David Blaikie <[email protected]> wrote: >> >> [oops, meant to move this to cfe-commits in the process] >> >> On Sun, Apr 29, 2012 at 5:11 PM, David Blaikie <[email protected]> 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 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
