Date: Sun, 30 Jun 2024 12:11:14 -0400
And P1949 has a ridiculously long appendix with the set of start and
continue characters as of when it was published, if you want to check.
This has also come up for a bunch of mathematical operators that are also
not identifiers, which are being used in some math libraries to make the
use look more like a rendered and inscribed mathematical formula.
(In reality mathematicians write LaTeX, and end up asking for the source
code to figure out what that squiggly was intended to be)
The Unicode group also has a lot of programmers, and is actively
researching this, it's most likely that we will continue to follow their
guidance.
Confusables are a whole additional problem, also with active research for
guidance. More complicated is that for typed compiled languages like C++
the attack surface is very different than JavaScript.
On Sun, Jun 30, 2024, 11:09 Alisdair Meredith via SG16 <
sg16_at_[hidden]> wrote:
> 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
>
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>
continue characters as of when it was published, if you want to check.
This has also come up for a bunch of mathematical operators that are also
not identifiers, which are being used in some math libraries to make the
use look more like a rendered and inscribed mathematical formula.
(In reality mathematicians write LaTeX, and end up asking for the source
code to figure out what that squiggly was intended to be)
The Unicode group also has a lot of programmers, and is actively
researching this, it's most likely that we will continue to follow their
guidance.
Confusables are a whole additional problem, also with active research for
guidance. More complicated is that for typed compiled languages like C++
the attack surface is very different than JavaScript.
On Sun, Jun 30, 2024, 11:09 Alisdair Meredith via SG16 <
sg16_at_[hidden]> wrote:
> 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
>
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>
Received on 2024-06-30 16:11:26