On Tue, Apr 28, 2026 at 4:48 PM André Offringa via Std-Proposals <
std-proposals_at_[hidden]> 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.
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 <https://mit-license.org/> (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.)
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.

"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.

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!

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.)

"private static" appears in the paper 11 times, and "static private" 10
times. I'm still not sure which one you're proposing. Make it clear what
you're proposing.

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.

"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.
And what about comparison operators? Swap? Conversion functions of the form
`private S::operator T() const`?

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.

HTH,
Arthur