I'm saying the phase 1 wording gives enough flexibility to perform or not trigraphs replacement, and that an implementation can choose to do that replacement or not in string, raw strings etc.
To get us back on topic, I'm arguing that we should do what the paper is proposing.
Provided that there is some clear agreement on how the ??=pragma use case could be handled in the long term within Clang (or more directly blessed by the standard), I am not against the removal of digraphs.
On that front, I think that a variation of the paper's 7.2, "Partially reintroduce trigraphs", would work: namely changing the directive syntax to accept ??= in place of #.
The status quo is that
- EBCDIC encodings can use trigraphs as a conforming extension
Yes, but depending on the form of the extension, it can harm the portability of C++ programs. For example, by replacing trigraphs in non-raw strings. It does seem that just leaving trigraphs on is working at this time though, but I am not comfortable with relying on that to hold.
- Encodings for which digraphs were standardized are no longer in use - they were obsoleted by the time digraphs were standardized.
This ignores Tom's point that digraphs can be used to write C/C++ such that an encoded file could be interpreted using multiple encodings without change in meaning. For example, by using only characters that encode the same way between the various encodings of interest. I personally make use of this to write tests having to do with different input encodings.
- The standard librarie prevent the existence of a conforming implementation that would not support ascii-like encoded source files
What are your supporting points for this statement? Perhaps you mean that such libraries introduce friction for cases where digraph usage would be required?