On Thu, Sep 23, 2021 at 8:21 AM Jens Maurer <Jens.Maurer@gmx.net> wrote:
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.

Recommended practice: Implementations should return a value that represents an en-
coding whose code unit size matches the size of a single wchar_t. 

> 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.

Agreed.
But I'd rather... find a way to move forward?


> * 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)

"Obviously broken" is a rather big claim in the absence of suitable alternatives.
I believe the use of  the IANA registry is motivated by the paper and previous polls.
I did however modify the paper to use more correct terminology and added a note to explain that our terminology differs, which will hopefully avoid confusion
 


Jens