On 23/09/2021 07.21, Corentin via SG16 wrote:
> I would like to know if you have sustained objections such that you do not want to see this paper polled, because that's currently not clear to me.

At this time (thanks Hubert for the digging), I think the normative wording
is sufficiently unclear in its intent that I'm strong opposed to forwarding
this paper to LWG.

Maybe some notes or "Recommended practice" sections would help convey what
we want implementations to do, if we can't describe that normatively with
sufficient precision.

> If so, I would like to know what direction you would like this paper to take.
>
> * We already made the wording as wide as possible, because it was always the intent of this paper to be on a best effort basis (I do not think a perfect solution can be found). I do believe the wording matches the intent sufficiently, please let me know if you think that's still not the case.

See my separate e-mail. I can't divine the intent from the wording right now.

> * We can remove wide methods. I'd argue that, at the very least, it's still useful for users to distinguish the few known and well-paved scenarios from everything else such that for example if an user expects utf-32 on posix they can check for that. Returning something like "x-ISO8859-1" is also useful on introspection, even if by definition this is very much none portable.

I'd guess that Hubert has situations where some wide-EBCDIC encoding is used.
Also, it feels asymmetric to talk about just narrow encodings, but not wide
ones.

> * We can stop pursuing this paper.

* We can divorce ourselves from the obviously broken IANA registry
(possibly just rely on their "character set definitions", but not claim
those are actual encoding designations)


Jens