On 4/29/26 00:44, Arthur O'Dwyer wrote:

On Tue, Apr 28, 2026 at 4:48 PM André Offringa via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

Hi all,

In follow-up on the discussion about private extension methods, I
updated the original draft from 2013 with results from discussion then
and now and placed it here:

https://github.com/aroffringa/stdcxx-privext-2026/blob/main/proposal/draft.md

You say "based on an earlier proposal from 2013 by Matthew Fioravante," but I don't see where you actually link to that earlier proposal. You should do that.

Fair enough. The git repo contains the license — I've added links to Matthew's proposal now inside the proposal as well.

You say "Large parts of his text were reused, following the MIT license," but on the one hand I'm sure you're not following the letter of the MIT license (since I don't see those letters anywhere in your text), and meanwhile since you don't provide a pointer to the original I would say you're not following the spirit, either. (I don't think the MIT license really applies to non-software anyway.)

The license file is in the repo, https://github.com/aroffringa/stdcxx-privext-2026 . I've added a link to it in the document.

You have a "References" section. That's (one of) the places I'd expect to see a link to the prior art you're talking about.

You have a "Changes compared to the 2013 proposal." That's a place I'd definitely expect to see a link to the 2013 proposal.

Good points, links were added.

"We will perform...", "Let us examine..." — I recommend to cut the cruft and just say what you're proposing, and why. Partly I'm grumpy because of how that useless 14-row table rendered on mobile; but even if I weren't grumpy, I don't think the proposal benefits from that 14-row table.

I'd agree the table is not super useful -- table removed, I surely don't want to make people grumpy ;).

You use the acronyms "PEM" and "PSEMF". Try not to need them: write out what you mean. If you must acronymize, be consistent — these are either "M"embers or "M"ember "F"unctions — pick one!

Changed to consistently use 'member functions' (what previously was called 'methods'). The abbreviations are quite useful in code examples.

If we allow the implementor to add private member functions via

private void Foo::newfunc() { }

private static void Foo::newfunc() { }

then should we also allow the implementor to add private static data members via

private static int Foo::sdm = 42;

? (Incidentally, this shows that your 14-row table is missing a bunch of rows.)

Agree. The now-removed table actually also misses aliases (which is not unimportant when discussing the syntax of reopening the class vs use of private before function definition).

I’ve considered whether to generalize this to broader class extensions or whether the focus should be on solving the issue of private member functions. Private static data members are indeed also not part of the interface and could be extended. The same holds for private type aliases.

However, my preference is to focus only on private member functions. I think they would be the most commonly used and imho most beneficial option to have. There are relatively simple alternatives for static data members (for example, one could just start a new class inside the implementation file), as well as for type aliases (just define them locally). This is not the case for private member functions (with internal linkage). I think there are more arguments, and I've summarized those now in a new section under "Private static data members and private aliases" in the draft.

Can the implementor's "private extensions" include declarations, or just definitions? That is, is this permitted?

struct S { };

private int S::f(int x = 0);

private int S::f(int x) { return x; }

I would think that it should be.

This was indeed not covered in the proposal, but is indeed a good addition. I think it should indeed be allowed, so that there's more flexibility in where the private extension member functions are defined. I've added a section to the proposal mentioning it.

"Note that we cannot declare private extension default constructors, copy constructors, ..." — What do you mean "note"? You didn't mention any of this before! And why can't we? This part can't just be a throwaway line as if it's obvious from context; you actually need to explain what you're talking about here.

Fair enough, I've added some motivation.

And what about comparison operators?

Other properties of PEMFs mentions that operator overloading is allowed (I at least don't see why not). The syntax seems trivial enough to me to not need an example.

Swap?

There's nothing special about swap functions, is there?

Conversion functions of the form `private S::operator T() const`?

This appears to not lead to issues; I’ve clarified that it is permitted.

Much of the confusion in your paper could be avoided if you'd just try to write some "Proposed Wording." Figure out what sections of the Standard would have to change, and show how.

Look at existing proposals to see how "Proposed Wording" is supposed to be formatted.

Agreed. The design of the feature is slowly settling, so I'll start working on a drafting such a section.

Thanks for the useful comments,

Regards,
André