This violates the principle that one should be able to make user-defined
types behave as if they were built-in types. We don't always support all of
that, but we try. We certainly don't go the other way.

In this case, it is impossible to make a user-defined class where operator.
does the same thing as operator->, because operator. is not overloadable.

There are other issues. One reason for having -> and . be distinct is to
see which operations dereference a pointer that is potentially null, and
which don't. Dot means "you don't need to be as careful". Arrows are
suspect.

I hear you that it is technically possible to make . behave the same way as
-> for raw pointers - but perhaps you should ask yourself why Ritchie and
Kernighan didn't do it. I am quite sure they saw the opportunity. Perhaps
they thought it was a dangerous idea?

Gašper

On Sun, Feb 16, 2020, 17:34 J Decker via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
>
> 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
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>