On Fri, Jan 05, 2024 at 05:57:47PM +0100, Corentin wrote:
> On Fri, Jan 5, 2024 at 5:47 PM Mark de Wever <koraq_at_[hidden]> wrote:
>
> > On Fri, Jan 05, 2024 at 04:26:49PM +0000, Jonathan Wakely via SG16 wrote:
> > > Since the adoption of P2736 C++23 and the current C++ working draft just
> > > refer to "the Unicode Standard", with a URL referring to the latest
> > > version. We removed the bibliography entry for TR29 revision 35. P2736
> > > gives the justification for this that the revision of #29 included in
> > > Unicode 15 (revision 41) is just a bug fix, so there's no problem
> > referring
> > > to that instead.
> > >
> > > That might have been true last year, but the current Unicode Standard
> > > (15.1.0) includes revision 43 of UAX #29, which makes significant changes
> > > to the extended grapheme cluster breaking rules. A new state machine is
> > > needed (and new lookup tables of properties) to implement rule GB9c.
> > That's
> > > not just a bug fix, is it?
> > >
> > > Are C++ implementations expected to implement rule GB9c, despite it not
> > > being part of the standard when C++23 was published?
> >
> > AFAIK this was indeed intended. The Unicode Standard moves at a faster
> > pace than the C++ Standard. This allows C++ to always use the latest
> > Unicode features and backport them to older language versions.
> >
>
> Right, the intent was to give implementers the freedom to keep up
> with unicode between standard versions if they so chose.

They way I recall it and read it in the Standard it is required to
use the latest Unicode release.

> The important part is that Unicode and its annexes represent an
> indivisible whole so it would not be conforming to, for example,
> update the properties tables but not the algorithms that use them.

Agreed

> Maybe that could be made clearer in the wording though

+1 if that was your intention.