On 1/23/22 3:39 PM, Corentin Jabot wrote:
>
>
> On Sun, Jan 23, 2022 at 8:44 PM Tom Honermann via SG16
> <sg16_at_[hidden] <mailto: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
> <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 designs are possible. SG16 will entertain competing proposals
should any arise.
>
> Different database = Different invariant = Different types.
>
> All of what SG16 discussed at this meeting was extensively covered in
> the paper and at previous meetings.
I don't agree. For example, I don't recall prior discussions about the
possibility of a class template parameterized by a registry ID.
> At the risk of repeating myself there is no need for future proofing here
Your perspective is not universally shared; the existence of P2498
proves that.
>
> * 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.
>
I believe there is disagreement within SG16 regarding that last point. I
believe your perspective and intent is well understood within SG16.

Please do not continue this discussion in this email thread. Feel free
to start a new one with an appropriate subject line to address specific
concerns if you like.

Tom.