On Sun, Jan 23, 2022 at 8:44 PM Tom Honermann via SG16 <sg16@lists.isocpp.org> wrote:

The summary for the SG16 meeting held January 12th, 2022 is now available.  For those that attended, please review and suggest corrections:

The meeting summary includes a list of wording changes between P1885R8 and 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg16