On Thu, Sep 23, 2021 at 5:16 AM Hubert Tong <
hubert.reinterpretcast_at_[hidden]> wrote:

> On Wed, Sep 22, 2021 at 5:33 PM Tom Honermann via SG16 <
> sg16_at_[hidden]> wrote:
>
>> On 9/22/21 5:18 PM, Corentin via SG16 wrote:
>>
>> Hello,
>>
>> I forgot to mention that Bryce asked on the reflector whether we want to
>> forward P1885 to electronic polling
>> https://lists.isocpp.org/lib-ext/2021/09/20049.php
>>
>> Hubert had some great feedback, which I hope to have addressed
>> https://isocpp.org/files/papers/D1885R8.pdf
>>
>> I'd like to see this paper forwarded, I would love it if either you could
>> indicate your support or let me know how I could increase consensus.
>>
>> I assume by forwarded, you mean forwarded from LEWG to electronic polling.
>>
>> I'm not aware of anything that would change the SG16 consensus for it,
>> but I haven't caught up on the recent discussions on the LEWG mailing list
>> yet either. I'll get caught up and follow up as necessary.
>>
> I think there have been a few surprises:
> Under the author's preferred interpretation of the charsets represented by
> the IANA Character Set Registry, few of the registered encodings are wide
> encodings. The wording is designed towards high implementation freedom, so
> I am not sure how much of the author's intent is going to be apparent to
> implementers (especially if individuals not directly participating in the
> threads of discussion happen to be the people who end up doing the
> implementation).
>
> Also, (this is new information to me and I expect to most people as well)
> the paper's prose points to GCC's -fwide-exec-charset option, which really
> only works if the option specifies a correctly-sized wide encoding that
> iconv recognizes.
>
> Observe:
> $ gcc -fwide-exec-charset=ISO8859-1 -fsyntax-only -xc++ -<<<$'extern char
> x[L\'0\'], x[0x30];'
> <stdin>:1:28: error: conflicting declaration 'char x [48]'
> <stdin>:1:13: note: previous declaration as 'char x [805306368]'
>
> So, insofar as the example in the prose is concerned, there would need to
> be an iconv name for the appropriately-sized wide EBCDIC encoding.
>


Thanks Hubert.
I added more prose.

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.
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.
* 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.
* We can stop pursuing this paper.

Thanks,
Corentin











> Tom.
>>
>>
>> Thanks :)
>>
>> Have a great day, corentin
>>
>> PS: I also forgot to mention that Jens's paper (p2314) will be in plenary
>> in october!
>>
>>
>>
>> --
>> SG16 mailing list
>> SG16_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>>
>