On Sun, Jan 23, 2022 at 8:44 PM Tom Honermann via SG16 <
sg16_at_[hidden]> wrote:

> The summary for the SG16 meeting held January 12th, 2022 is now
> available. For those that attended, please review and suggest corrections:
>
> - https://github.com/sg16-unicode/sg16-meetings#january-12th-2022
>
> The meeting summary includes a list of wording changes between P1885R8
> <https://wg21.link/p1885r8> and P1885R9 <https://wg21.link/p1885r9> as
> requested to substantiate the "Wording fixes" entry noted in the revision
> history of the latter revision.
>
> No decisions were made at this meeting (we did not have quorum due to
> lower than usual participation).
>

   -

   Jens stated that there is a procedural question related to the changes
   made in this revision; the new draft changes the design after electronic
   polling

There is no question, LEWG needs to see the paper again


   -

   PBrett asked for more details regarding implementation as a function
   template and whether the functions could simply not be declared at all.

CHAR_BIT is macro, there is no need for templates

#if CHAR_BIT != 8
consteval auto literal() = delete;
#else
...
#endif

   - Tom added that a non-conforming implementation would map to "other" in
   that case.

Mapping an encoding to a value is implementation defined, and conforming.
IANA is used as a collection of names.
There needs to be implementer freedom here, a lot of existing practice that
we need to allow for.


   - PBrett replied that there are NB concerns about IANA being an
   unregulated, unaccountable, and unreliable organization.


While I strictly don't care about the names, if there are concerns about an
organization, should we bake its name in the api?
Mib is agnostic of the managing organization, the elements of values here
are the aliases, ids, and their mapping.

General comment:

P1885 is an abstraction over the datas and values In the IANA database and
corresponding RFCs.
This is the invariant of the class. In no case is it suitable to support
arbitrary databases (we could add a isWhatWGEncoding() if desired)

The choice of IANA is detailed in P1885, and does in fact check the most
boxes

   - Best coverage of encodings among the vendors including ibm and
   windows, compile time enforcement of validity - by the mib enum
   - support of implementation specific aliases
   - support of unregistered encodings.

I encourage people to look at the cited databases, and the annexes in
P1885. It doesn't take long to see why they are not suitable.

The invariant of the class cannot be extended. On the hypothetical of
multiple db with the same names mapping to maybe different things, how do
you define equality, or construction?
Supporting arbitrary things would also increase the amount of runtime data
needed to make this work.

Different database = Different invariant = Different types.

All of what SG16 discussed at this meeting was extensively covered in the
paper and at previous meetings.
At the risk of repeating myself there is no need for future proofing here

   - Whatever iana becomes in the future will not invalidate the data, and
   we could change the reference in the standard without impacting
   implementations - unless we call "iana" out specifically" in the api,
   ironically.
   - There are no new encodings being registered frequently
   - The class is intended for compatibility purposes, it is not and
   doesn't need to be future looking.




Tom.
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>