On Tue, Jun 13, 2023 at 1:46 PM Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Tuesday, 13 June 2023 07:46:08 PDT Arthur O'Dwyer via Std-Proposals
> wrote:
> > Rewritten to use names that are clearly members or types:
> > struct A { int x_, y_, z_; };
> > struct B { A a_; };
> > struct C { B b_; };
> > B C::*pb = &C::b_; // OK
> > int C::*px = &C::b_::a_::x_; // Proposed
> > int C::*py = &C::b_.a_.y_; // Maybe better syntax?
> > int C::*pz = (&C::b_).a_.z_; // Maybe even better syntax?
>
> I'd still prefer:
>
> int C:: *pmfx = &C::b_ + &B::a_ + &A::x_;
>
[...]

> int *px = &obj_c + pmfx;
>
[...]

> A int::* = -&A::y;
> A *a = py - &A::y;
>

That's intriguing — basically allow "member-pointer math" in the same way
that we already allow "pointer math"!
At that point I start worrying mainly about moral hazard — at what point,
if any, do we say "no, users who want to mess with arbitrary mappings from
`A` to `int` or vice versa should just start composing together lambdas"?
This feels uncomfortably close to Ranges' bad habit of using `&A::dm` to
mean `[](auto&& x) { return x.dm; }` — misusing member-pointer syntax to
create an orthogonal mini-language. But that's a vague and non-technical
objection, and also one I might grow out of in time.

Thiago (or anyone), if you went with the +/- syntax, how would you prefer
to spell the "array element subobject" and "base subobject" transformations
I mentioned? Is there a natural syntax for those?

–Arthur