On Sun, Feb 2, 2025 at 2:02 PM Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Sunday 2 February 2025 03:38:31 Pacific Standard Time Jonathan Wakely
> via
> Std-Proposals wrote:
> > > I understand this viewpoint; but in having accepted '.' (in a post '.'
> > > derefercing pointer view) it is a consistent behavior to access a
> member
> > > of an object rather than 2 methods.

[...]
> The C standards committee may decide it's beneficial to their language to
> add
> that, under their own rules.


C doesn't want `.` to behave like `->` either.
There's simply no justification for the idea.
The presented idea is: "Well, C's pointer types don't support `.`, so let's
just allow `p.x` to be syntactic sugar for `(*p).x`: the compiler should
interpret the one as meaning the other."
One might as well say: "Well, C's array types don't support `()`, so let's
just allow `a(i)` to be syntactic sugar for `a[i]`: the compiler should
interpret the one as meaning the other."
Or: "Well, C's pointer types don't support unary `-`, so let's just allow
`-p` to be syntactic sugar for `--p`: the compiler should interpret the one
as meaning the other."
Or: "Well, C's pointer types don't support `%`, so let's just allow `p % 2`
to be syntactic sugar for `*p % 2`: the compiler should interpret the one
as meaning the other."
These ideas are all equally worthless; all they do is sop up syntactic
real-estate and bring the language closer to Perl or Befunge-style line
noise — in which any random collection of characters forms a valid program.
That's the exact *opposite* of a salutary design goal for C++.

–Arthur