On Tue, 2017-04-25 at 12:11 -0400, Nathan Sidwell wrote:
> On 04/25/2017 11:58 AM, David Malcolm wrote:
>
> > { return FIELD; }
> >
> > for the correct field, favoring returning T to returning T&.
>
> Hm, that seems the poorer choice (unless you can suggest both).
> After
> all the T& case will meet the rvalue case (const-qualifiers
> ignoring). I
> suppose if thing is 'T const *':
> thing->field;
> you could rule out any non-const qualified accessor?
Ahhh, the patch erroneously offers get_color as a suggestion for this
case:
class t1
{
public:
int& get_color () { return m_color; }
private:
int m_color;
};
int test_const_ptr (const t1 *ptr)
{
return ptr->m_color;
}
which, if the user applies the bogus suggestion would then fail with:
error: passing ‘const t1’ as ‘this’ argument discards qualifiers
return ptr->get_color ();
^
I tried adding the kind of filtering you suggest, but the binfo doesn't
seem to have info on const vs non-const qualification of the accessor.
So I tried adding a param for this to maybe_suggest_accessor, but then
we need to pass the information to perform_or_defer_access_check, and
to lookup_member, and it thus becomes quite an invasive change (I don't
have it working yet).
Any thoughts on how to implement this?
Or maybe to narrow the scope of the patch so that it only suggests
const accessors?
Thanks
Dave
