I would not be so quick to abandon the idea, as I think many common units
and modifiers like micro will be supported, although it may mean approximating
with the original greek letters.

I would not be in favour of extending beyond what Unicode has chosen to support.
I believe that part of the database is supposed to be stable, and I don’t want to
argue with the body of world experts on what is a reasonable choice for multilingual
identifiers, even if we think they got it wrong! As C++ experts, we have more
important places to focus our attention.

So support what is supported — in technical code bases that are prepared to
invest in broader Unicode support for code entry, that would definitely lead to
clearer code, and on a subject that this library itself is addressing because
precision (and clarity) matters.

AlisdairM

> On 30 Jun 2024, at 11:11, Mateusz Pusz <mateusz.pusz_at_[hidden]> wrote:
>
> Thanks, Alisdair!
>
> If this is the case, we should probably abandon the idea, or if we really care about it, think about extending the allowed Unicode range.
>
> niedz., 30 cze 2024 o 17:09 Alisdair Meredith <alisdairm_at_[hidden]> napisał(a):
> I believe the diagnostics you receive are correct — the later symbols do
> not have the XID_Start property, e.g.,
> https://codepoints.net/U+2103
>
> AlisdairM
>
> > On 30 Jun 2024, at 10:56, Mateusz Pusz via SG16 <sg16_at_[hidden]> wrote:
> >
> > Hi,
> >
> > During the recent LEWGI discussion on the units library, people in the room suggested that in addition to the regular "ASCII" version, we should also provide Unicode symbols for unit identifiers. It seems that with P1949R7, this could be possible.
> >
> > However, when I tried this in the code, I was able to make the following work:
> >
> > inline constexpr auto µΩ = micro<si::ohm>;
> >
> > but not:
> >
> > inline constexpr auto ℃ = degree_Celsius;
> > inline constexpr auto ° = degree;
> > inline constexpr auto ′ = arcminute;
> > inline constexpr auto ″ = arcsecond;
> >
> > Are those outside of the supported range and should not be supported, or is it just the lack of proper support in the compilers I use (gcc-14 and clang-18)?
> >
> > Even if this can work, is it a good idea?
> >
> > Best
> >
> > Mat
> > --
> > SG16 mailing list
> > SG16_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>