On Sun, Feb 16, 2020 at 1:03 AM Bo Persson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On 2020-02-16 at 05:45, J Decker via Std-Proposals wrote:
> >
> >
> > On Sat, Feb 15, 2020 at 8:40 PM Arthur O'Dwyer
> > <arthur.j.odwyer_at_[hidden] <mailto:arthur.j.odwyer_at_[hidden]>> wrote:
> >
> >
> > On Sat, Feb 15, 2020 at 11:10 PM J Decker <d3ck0r_at_[hidden]
> > <mailto:d3ck0r_at_[hidden]>> wrote:
> >
> > On Sat, Feb 15, 2020 at 7:07 PM Arthur O'Dwyer
> > <arthur.j.odwyer_at_[hidden] <mailto:arthur.j.odwyer_at_[hidden]>>
> > wrote:
> >
> > Hi Jim,
> >
> > Sadly your idea doesn't work in C++, because C++ has
> > /*member functions*/. That is, we can write things like
> this:
> >
> > struct Widget {
> > void reset(); // reset the widget
> > };
> > [...]
> > std::unique_ptr<Widget> p = std::make_unique<Widget>();
> > p->reset(); // reset the pointed-to widget by calling
> > Widget::reset() member function
> > p.reset(); // reset the pointer's own value to nullptr
> >
> >
> > But, isn't the .reset() implemented on the unique_ptr<> template
> > as a operator. override? which takes precedence over the
> > default behavior...
> >
> >
> > No, C++ doesn't permit overloading the "." operator at all.
> > It's just that `p.reset()` calls `unique_ptr<Widget>::reset`,
> > and `p->reset()` calls `unique_ptr<Widget>::operator->` followed by
> > `Widget::reset`.
> >
> > I think you'll have to learn more about how C++ currently works,
> > before working on proposals to change it.
> >
> > A appricate you leveraing my acknowledgment of limitation as a
> > dismissal; it's more a factor that I need to learn the right way to say
> it.
> >
> > It doesn't look like that's either a instance of a class/struct/union or
> > a pointer to a class/struct/union, but rather is a unique pointer to a
> > class/struct/union.
>
> It's just that unique_ptr *is* a class from the C++ standard library.
>
> And that it, like Arthur says, already has both . and -> defined, but
> with different meanings. So making the operators mean the same thing
> doesn't look as a good idea, as it breaks existing code.
>
> But, again, the case that matters is an error

struct x {
   int a;
};
void f( void ) {
   struct x X;
   struct x *pX;
   int t;
   t = pX.a; // this is an error, not a 'accesses some other function in a
class instance'
   t = X->a; // this is an error; not an alternate access method; although
I'm not actually interested in 'fixing' this direction
}

There is no breaking of existing code, all exiting code that works should
continue to work.
But in the case that the error condition is hit for '.' it could behave
like '->', and the title of this thread is bad.

J


> Bo Persson
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>