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_at_[hidden]> wrote:

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