N4267によって提案されたこれらのポイントは正確には何ですか?
それらの唯一の機能は、拡張 ASCII 文字または部分的な UTF-8 コード ポイントが指定されないようにすることのようです。それらは依然として固定幅の8ビット文字で保存されます（私が理解しているように、これはほとんどすべてのユースケースでとにかくUTF-8を処理するための正しい最良の方法です）。全て。何が起こっている？
(実際には、UTF-8 文字列リテラルの必要性を理解しているかどうかも完全にはわかりません。Unicode の検証と組み合わせた Unicode 文字列で奇妙な/あいまいなことを行うコンパイラの心配だと思いますか?)
論拠はEvolution Working Group issue 119 でカバーされています: N4197 u8 文字リテラルの追加、[小さい] なぜ u8 文字リテラルがないのですか? 提案を追跡し、次のように述べています。
文字列リテラルには 5 つのエンコーディング プレフィックス (none、L、u8、u、U) がありますが、文字リテラルには 4 つしかありません。不足しているのは、文字リテラルの u8 です。
これは、狭い実行文字セットが ASCII でない実装では重要です。そのような場合、u8 文字リテラルは、保証された ASCII エンコーディングで文字リテラルを記述する理想的な方法を提供します (単一コード単位の u8 エンコーディングは正確に ASCII です)、しかし... 私たちはそれらを提供しません。代わりに、できる最善の方法は次のようなものです。
char x_ascii = { u'x' };...コードポイントが「char」に収まらない場合、縮小エラーが発生します。(これは u8'x' とまったく同じではないことに注意してください。コードポイントが UTF-8 で単一のコード単位として表現できない場合、エラーが発生します。)