[format.string.escaped] Fix invalid example #5890
Conversation
Example 5 should only have one invalid code unit. The second code unit is a valid code point. This issue was already in the paper P2286R8 Formatting Ranges
|
@cor3ntin, could you please take a look? |
|
@tkoeppe This is borderline design as the wording does not specify what constitute an invalid code unit sequence I think the proposed change is consistent with sg-16 consensus on what the behavior should be. A conservative approach would be to remove the example entirely. |
|
The proposed change illustrates the intended behavior. The example was previously discussed on the SG16 mailing list (see the thread with subject "Handling ill-formed Unicode in the library") and multiple people expressed support for the change while no one voiced opposition. Corentin is correct that the specification lacks a concrete description of how the boundaries of an ill-formed code unit sequence are determined. Addressing that will require normative changes to [format.string.escaped]. I'm confident that any changes made there would be consistent with the amended example; SG16 is highly unlikely to endorse any ill-formed code unit sequence definition that is not aligned with Unicode PR-121. |
|
OK, thanks, everyone! @tahonermann: are you tracking the specification deficiencies in an issue elsewhere? I'll apply this change and close this PR in the meantime. |
|
@tkoeppe, I am now: sg16-unicode/sg16#80. |
Example 5 should only have one invalid code unit. The second code unit is a valid code point. This issue was already in the paper
P2286R8 Formatting Ranges