On Sunday 14 April 2024 13:55:54 GMT-7 Frederick Virchanza Gotham via Std-
Proposals wrote:
> But anyway more to the point: I don't expect the compiler vendor to
> copy-paste my code into their compiler (which might be written in C
> anyway). They can implement the new feature in assembler if they want.
> The point of my "possible implementation" is to show where the data is
> and how it can be gotten.

But you're opening yourself to critique on something that is entirely
irrelevant. Instead of focusing on what's important in your paper, people will
focus on the disposable implementation. Whether they should is besides the
point. They might because it's human nature.

You'd show a possible implementation if it has a chance of being used and
therefore you'd spend time to write one that is clean and works for purpose.
That's what was done for atomic_wait[1], for example. In the end, none of the
compilers adopted it, but it was sufficiently clean that it could be used for
testing. What's more, the implementation wasn't part of the *paper*; it was in
Olivier's GitHub site.

And in any event, this is also besides the point. If your paper has a good
section on why the feature is useful and what problems (plural!) it solves,
the hacky implementation will be ignored. So just focus on writing a really
good motivation section.

[1] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1135r6.html

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Principal Engineer - Intel DCAI Cloud Engineering