Date: Sat, 2 Apr 2022 19:47:44 +0000
From: Austin Group Bug Tracker <nore...@msnkbrown.net>
Message-ID: <e927baab7405c0988724fd264330d...@austingroupbugs.net>
| That indented paragraph of yours (in Note 0005775) should (if at all)
| only go to the Rationale, IMO.
That's fine.
| Cause for the purpose of the standard itself it's not really relevant
| *why* they mustn't be used, but only *that* this is the case.
Actually there's no reason to forbid them, they simply do
not work. Applications cannot expect them to work.
That's all that needs to be said.
| Also, I'd rather really forbid their use,
That doesn't work for your intended purpose, as implementations
are permitted to extend the standard -- to give interpretations
to inputs that have either unspecified results, or which applications
shall not use.
To prevent that the standard would need to give an interpretation
to what these sequences must do, but I kind of doubt that in this
area there's an actual established standard to do that (do
remember that the purpose here is to document tbe existing
standard, not to define (invent) what that should be).
| Simply because otherwise an (crazy) implementation might try to
| "workaround" that limitation in some odd way, which again makes it
| non-portable.
That's fine, just an extension. Those exist all over tbe place.
We neither really can, nor should, attempt to prevent that. That's
how innovation happens. Without that we get revolution instead.
Innovation allows applications that restrict themselves to the
standard idioms to continue to function. Revolution does not.
kre
