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