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.