Hi Steve,

I'm not entirely clear what you mean. I'm in favour of bumping to
Unicode 15 and address LWG-3780. For now I created a PR to update libc++
to use Unicode 15. (That PR will land after approval by a reviewer.)
When users start to use Unicode 15, it may not estimate the width for
the new code points correctly, but without updating there would be the
same issue. Updating to Unicode 15 will allow libc++ to properly use the
new code points in the EGC.

Mark

On Sun, Sep 18, 2022 at 10:58:21PM -0400, Steve Downey wrote:
> If it's not clear what to do, it's an issue whether we bump the version now
> or later. Kicking the can down the road for something we mean to be
> floating helps no one.
>
> In general, though. this is a by programmer, for programmer, thing that no
> one else cares about or is affected by. I have a tragic user-facing
> infamous bug from a programmer parsing `ls -l` rather than using `stat`,
> and this is an area we should not care deeply about, or worry too much
> about portability, because that is the direction of madness.
>
> On Sat, Sep 17, 2022 at 3:22 PM Mark de Wever <koraq_at_[hidden]> wrote:
>
> > On Tue, Sep 13, 2022 at 08:19:29PM -0400, Steve Downey via SG16 wrote:
> > > What implementation headaches would it cause to bump our Unicode
> > reference?
> > > TR31 identifier characters and named escapes might be impacted? Neither
> > of
> > > which is hard, but are still some work.
> >
> > I've created PRs for libc++. The only issue is, what to do with the
> > width estimation of std::format for the new code points? For now I left
> > it unchanged. This is the same issue Corentin spotted and filed as
> > LWG-3780.
> >
> > Mark
> >