On Tue, Jun 13, 2023 at 1:46 PM Thiago Macieira via Std-Proposals <std-proposals@lists.isocpp.org> 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