On Fri, Mar 1, 2024 at 12:08 PM Jan Schultke <janschultke_at_[hidden]>
wrote:

>
> Everything deprecated would become ill-formed in the future, or would
> have its meaning altered by a future proposal that claims the syntax.
> [...]
> I also want to keep what will become of the syntax intentionally
> vague, since we don't know whether it will be removed or reclaimed.
> All the developer needs to know is what is getting deprecated.
>

As a working programmer, I think the difference between
- "We're deprecating this, in order to make it ill-formed in the future
(your vendor will likely support it indefinitely with a warning)"
- "We're deprecating this, in order to *alter its meaning* in the future
(you *must* move off it or risk your code silently breaking later)"
is highly significant. Your proposal is mixing both kinds of change in the
same paper — which is 100% fine IMHO, but I'd like a nice clear table of
which of your changes fall into which bucket, so that the reader can be
informed.
This is significant for programmers, but also significant for compiler
vendors, too, because they're the ones who will have to craft the wording
of their compiler diagnostics for those two distinct cases.

–Arthur