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 <https://en.wikipedia.org/wiki/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)
<https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2279r0.html>..."
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
<https://quuxplusone.github.io/blog/2018/06/12/attribute-noexcept-verify/>
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



On Tue, May 2, 2023 at 8:23 AM Chen Zhige via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Dear All:
>
>
>
> Here is a proposal of exploring to building a external polymorphism
> mechanism on C++0x concepts and Circle interfaces.
>
>
>
> Zhige
>