On Sun, Feb 16, 2020 at 1:03 AM Bo Persson via Std-Proposals <std-proposals@lists.isocpp.org> 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@gmail.com <mailto:arthur.j.odwyer@gmail.com>> wrote:
>
>
>     On Sat, Feb 15, 2020 at 11:10 PM J Decker <d3ck0r@gmail.com
>     <mailto:d3ck0r@gmail.com>> wrote:
>
>         On Sat, Feb 15, 2020 at 7:07 PM Arthur O'Dwyer
>         <arthur.j.odwyer@gmail.com <mailto:arthur.j.odwyer@gmail.com>>
>         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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals