Hi Zhige,

I don't have much to say on the meat of the paper, because the cosmetic formatting issues make it hard to read quickly. (Other people with more time might provide more meaty comments. You do seem to be well aware, intellectually, of the value of readers' time; I'm just not sure you've found the best way to translate your concern into practice. ;))

- I recommend using Bikeshed format for papers; check out https://github.com/Quuxplusone/draft/blob/gh-pages/Makefile to see how easy it can be. Bikeshed automatically creates an HTML paper with a table of contents in the left sidebar, which is great for the casual reader to get a sense of what you're going to say and in what order.

- Even if you don't use Bikeshed, write a table of contents.

- Write an abstract. Say what you're proposing, quickly and at a high level (but not so high that it turns into marketing-speak or management-speak: "Enable customization of library facilities with newbie-friendly syntax" is much too vague to be useful. What's the "elevator pitch" for your proposal? That's your abstract.

- I recommend a non-punny paper title. "implement C++ : interface" doesn't tell me what this paper is about, at all. My first guess was that it would be somehow related to `extern "C++"`. If what you mean is "Rust-like traits with Circle-like syntax", make that your title. (I have no idea if that's what you mean, because I haven't read the paper well enough to know. But you know, and you should teach me by writing a clear title.)

- The intro paragraph refers to P2279R0 and P2561R1, then later P2547R1, using only their numbers. I recommend adding their titles also, e.g. "Consider the examples shown in P2279R0 "We need a language mechanism for customization points" (Revzin 2021)..." For papers with opaque titles, IMHO it's reasonable to make up short identifying "titles" even if the author didn't — e.g. maybe P2561R1 "An error propagation operator" is clear enough, or maybe you want to say P2561R1 "Error-propagating `operator??`" or something like that. This is also a good reason to give your own paper a short clear title.  (Note that I failed at this in P1144R0–R6 "Objection relocation in terms of move plus destroy," and so P1144R7 is finally just called "std::is_trivially_relocatable", since that's more or less what everyone was calling it anyway.)

- OTOH, the fact that I don't know any of those papers from their numbers alone might simply indicate that I'm not in the target audience for this paper. There's nothing wrong with that. Just make sure your paper does have an audience — that you haven't in one way or another turned off everyone who might possibly have been interested in reading it. :)

- In the "Syntax(Bikesheddable)" section, please use the same formatting as the real Standard — italics for non-terminals, subscript_opt instead of [brackets] for optional components, and so on. This will save the reader's brain from having to learn an ad-hoc mini-language of your own invention. The reader can be expected to already know the particular mini-language used by the real Standard.

Maybe I'm missing the point, but I don't see what you mean by "customization" in the intro section. You give two code snippets:

- P2279's proposed desugaring of `operator??`, which relies on `std::error_propagation_traits` in the same way that the desugaring of a structured binding or `co_yield` in C++20 relies on `std::tuple_element` or `std::coroutine_traits`, respectively. (Btw, why not just use one of those C++20 facilities as your example? Why bring P2279 into it at all?)

- P2547's mechanism for (IIUC) providing a "fallback implementation" for derived operations like `!=` in terms of `==` (or, say, `operator+` in terms of `operator+=`, or `operator++` in terms of `.increment`). I'm a bit confused by the end of this example, which says "...and call it," but ends up calling the hidden-friend `eq` just as if none of the novel syntax had been there at all, correct? Shouldn't it be showing a call to `ne` instead?

And then you say "Compared to the status quo..." — But what is the status quo?  For the P2279 example, the status quo (for bindings and `co_yield`) is literally the same as what P2279 proposes, right? (Customize a magical library traits class; core-language syntax magically dispatches to that traits class as a special case.)  And for the P2547 example: I haven't read P2547, but it seems to me that (regardless of whatever else is proposed in the paper) the example you show is exactly isomorphic to the status quo, it's just got a lot of extraneous novel syntax. Mechanically all that example is doing is—

// https://godbolt.org/z/f7veMesMv

All I had to do to get it to compile as C++20 was:

- change a few of the `T`s to `auto`

- fix the syntactically invalid `noexcept` specifier (N.B. I did not fix the rogue std::terminate that occurs here when `eq(x,y)` is nothrow but `!eq(x,y)` is not)

- fill in a default implementation for `eq(double, double)`

- comment out all of the novel keywords

I'm sure P2547 proposes more than this. My points here are simply:

- To P2547's authors (whom I'll email in a minute): If you pursue an R2, consider fixing the (presumably relatively trivial) typos in this example;

- To Zhige: This example is not a good one for you to focus on, because it doesn't actually show off any of the features proposed by those authors. You described it as an improvement over the status quo; but in fact it is literally the status quo. This apparent mistake makes me suspect that the rest of your paper is going to be similarly off in the weeds.

Your paper certainly seems to depend on a lot of not-(yet)-accepted proposals by other people. Consider providing an index of all the "prerequisites" that would have to get standardized before your idea would even be possible — and mark each of them as "must-have" or merely "nice-to-have." For example, what happens to your proposal if `template<template auto X>` is never standardized? Does your whole idea go out the window, or can you salvage it somehow?

HTH,

Arthur