Sorry for the double reply; the example if modification is inversed logic; as a '.' it should accept a pointer input in the error case, not a instance. (I'm sure there are better words defined in the standard)

On Sun, Feb 16, 2020 at 10:10 AM J Decker <d3ck0r@gmail.com> wrote:
Thanks...good points...

On Sun, Feb 16, 2020 at 9:47 AM Gašper Ažman <gasper.azman@gmail.com> 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@lists.isocpp.org> wrote:


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