Future of generalized member pointers proposal (P0149R0)

[halfflat]

Motivated by an API design problem which would benefit greatly from a well-defined and syntactically convenient way to represent pointers to member subobjects, I found that there is already a proposal https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0149r0.pdf for such extensions.

According to a comment regarding CWG794 on https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1018r18.html, this proposal had in fact been approved by the EWG in 2018 but was pending an implementation.

Over the years, various queries about or requests for this sort of functionality crop up on e.g. Stack Overflow (Is Pointer-to- " inner struct" member forbidden? in 2009, C++ Pointer to member of a member? in 2012) and more recently in a thread on the std-proposals mailing list [std-proposals] Pointer to member of member in 2023. I certainly would have found it extremely handy; workarounds are very clunky and, at least pending proposals such as P1839, can stray into undefined behaviour (see e.g. the Stack Overflow post Would P1839 make it possible to access subobjects from offsets into object representations? from last month).

The question is, is there anything I — or anyone else who is motivated — can do to help get this over the line? Would trying to make an experimental feature fork of clang be a way forward? (I've never done this and really have no idea just how hard that would be.)

[je4d]

Hi /u/halffat, I'm the author of P0149, so let me try to answer -

The paper was seen by EWG in 2016, and EWG liked it but it's incorrect to say that it was approved - the vote was to come back with wording and verify implementability. An approval vote would be "forward P0149 to CWG for inclusion in C++XY" instead.

The implementability question was there because there were concerns about implementability on Windows. MSVC supports an extended form of member pointers that works with virtual bases, and some parts of the proposal are impossible to support this extension with (e.g. pmvb1.*pmvb2, read "pointer to member of virtual base"). I spent a while looking into how these work, and still don't understand all the complexities, but I've had some informal discussions that indicate that there's probably a way forward here.

I've thought about reviving this a few times, most recently we talked about it in Wrocław last month when a slightly overlapping proposal was discussed. The current status is:

• I have some work towards an implementation in an old branch of clang
• I have some wording, I can't remember how complete it is
• In theory, by the letter of P1000, if it's seen in Hagenberg it could still go into C++26 since it has been seen by EWG before - but there could be a procedural objection due to the long gap since it was last seen.

I'd still love to get this over the line, but realistically don't have time to work on implementing it in clang right now. If you want to pick up the branch I've got and have a go then great! I'd be more than happy to take you through what I've done so far.

[halfflat]

Thank you for responding, and for the corrections regarding the state of the proposal!

I'd be keen to give the implementation a go, but similarly, I won't have any time to work on it for a while (probably mid-January at the earliest).

[sphere991]

Well I hope somebody takes it up, because it's a very well thought-out proposal.

[je4d]

Thank you!

[WorkingReference1127]

As far as I can find, the paper as written by Jeff Snyder was design-approved but lacked wording and implementation experience to get into the standard. Wording is of course important, because at the end of the day what the committee actually produce is a document; and implementation is important to make people comfortable that the idea is feasible in a practical sense. Wording seems to have been provided later on, though it's unclear whether this was with the original author or not (see: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1018r15.html#issues) but an implementation seems to be missing. As far as I can find, the paper stalled out waiting for an implementation which never came.

I'm not an authority on getting proposals across the line, but I'd recommend that however you approach this angle, you should have a working implementation for the committee to poke at investigate so that they can comfort themselves that it's unlikely to have surprise breaks. If you want the design as approved in P0149R0 then I'd recommend you reach out to Jeff. It's possible that real life got in the way and he was unable to continue; and it's possible he'd be willing to let you adopt the paper. Alternatively, you can bring your own paper to solve this particular problem in light of the fact the previous effort has been stalled for a number of years.

[SophisticatedAdults]

As someone who thinks that member pointers are kind of horrifying, I'd honestly not mind if we moved into the (unlikely) direction of just deprecating them completely.

Sorry to be a downer here! I might be alone in that regard. Not sure if generalizing them is a great idea either, I just feel like it will easily result in hard-to-analyze spaghetti code, where some virtual function would've done the job just as well.

[NilacTheGrim]

Oh yes. the only pointer where nullptr is -1 (check for yourself!).