Thanks...good points...

On Sun, Feb 16, 2020 at 9:47 AM Gašper Ažman <gasper.azman_at_[hidden]> wrote:

> 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.
>
so there's no possibility of impacting existing code....


>
> 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.
>
That's a fair point; however, for debugging practices, you have a thing you
can mouse over and see the value... so you may end up checking more parts
of an expression than previously done (although nothing prevents you from
using -> to denote this IS a pointer as a matter of style)... if you chose
to use '.' then instead of 'print s->x.y.z.' hmm I suppose then like the
expression handler in GDB has to be updated....

And really I didn't intend to make/imply that -> should also behave like
'.', other than I did, because of the other patch I did. That is a
definite edit note. The only requirement is really to support '.' where ->
was previously only accepted. It should be really easy to track down that
error message, and add a if( is instance of thing ) { /* return the
reference to the thing instead of reading the pointer */ } else { /*
existing error */ }


>
> 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?
>
'.' as an operator in JS is always suspect... so the ideaology becomes that
every access of a member can be suspect, and you can't just skip over ones
that obviously can't be?

I'm pondering all the things I omitted from the initial post, and am still
thinking of how to organize this.

J


> 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
>>
>