On Thu, Mar 5, 2020 at 12:41 AM Andrey Semashev via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On 2020-03-05 06:09, J Decker wrote:
> >
> >
> > On Wed, Mar 4, 2020 at 5:11 PM Andrey Semashev via Std-Proposals
> > <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>>
>
> > wrote:
> >
> > On 2020-03-05 03:44, J Decker via Std-Proposals wrote:
> > > Reformatted this to resemble standard proposal
> > >
> > > https://gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280da
> > > It fails to be ' The proposal may be in PDF, HTML, or plain text
> > formats. '
> > >
> > > TL;DR
> > >
> > > C Standard section 6.5.2.3 Structure and union members
> > >
> > > add text in [ ]
> > >
> > > 1- The first operand of the . operator shall have a qualified or
> > > unqualified structure or union type or [‘‘pointer to qualified or
> > > unqualified structure’’ or ‘‘pointer to qualified or unqualified
> > > union’’,] and the second operand shall name a member of that type.
> > >
> > > C++ Standard section 8.5.1.5 Class member access
> > >
> > > add: if the first expression of (dot) is a pointer [to an
> > object], then
> > > E1.E2 is converted to (*(E1)).E2 .
> >
> > I don't find your motivation compelling. The other languages you
> refer
> > to (which ones? Java? JavaScript?) likely don't have the concept of a
> > pointer and thus don't need a separate operator. You've been shown
> > examples where having operators . and -> behave the same would break
> > code. Special casing the proposal just for raw pointers is breaking
> > consistency. So no, just no.
> >
> >
> > I'm sorry I have seen 0 examples where they conflict in meaning and
> > don't continue to work the same way.
>
> Smart pointers were given as an example.
>

Smart pointers continue to work as they do, because they are an object that
contains a pointer to an object, and are not 'pointers'. they are of a
class type 'smart pointer', they are not pointers to a class of type 'smart
pointer'.

I provided examples, in this list and updated in the gist, of how pointer
to smart pointers can still work, and actually '.' operator which can
perform indirection can simplify that use case by still just being 'access
property of pointer'.

-- 
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>