On Sat, 4 Jan 2020 at 22:20, Thiago Macieira <thiago_at_[hidden]> wrote:

> On Saturday, 4 January 2020 12:32:00 -03 Corentin Jabot wrote:
> > Comparison.... basically the only use (2 text encoding with the same mib
> are
> > identical, although the primary iana name might do), and you can compare
> a
> > MiB to a text_encoding directly. I still think it's useful to have a
> method
> > that gives you the mib when it is known so you can interface with a few
> > libraries that use it. But beyond that I don't think we should focus on
> > MiB.
>
> Sure, but then we'd have something like:
>
> enum class mib : uint32_t {
> // names match
> // https://www.iana.org/assignments/ianacharset-mib/ianacharset-mib
> other = 1,
> unknown = 2,
> csASCII = 3,
> csISOLatin1 = 4,
> csUTF8 = 106,
> csUTF16BE = 1013,
> csUTF16LE = 1014,
> csUTF16 = 1015,
> csUTF32BE = 1017,
> csUTF32LE = 1018,
> csUTF32 = 1019
> };
>
> However, a more powerful way for comparison would be to have a
> text_encoding_id class that can compare to mib and to itself. It would be
> able
> to tell whether two unlisted (and possibly unregistered) encodings are the
> same, whereas mib can possibly fail. This tex_encoding_id class can have a
> mib() accessor that returns a mib number, but may return mib::other.
> Hence,
> direct mib comparison should be discouraged in favour of text_encoding_id.
>


This is *exactly* what is proposed.
They compare equal if:
 * they have tyhe same mib
 * they have the other mib and their name compare equal (under the
comparison algorithm ignoring case dash and a few other things)


>
> > Otherwise I agree, an implementation needs to only provide the encoding
> it
> > cares about. (important for embedded platforms where the encoding never
> > changes)
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel System Software Products
>
>
>
>