Date: Mon, 14 Aug 2023 13:09:56 -0400
Hubert, could you comment on your question about exposing the
transcoding iterator hierarchy unpacking? Do you feel that your question
has been adequately answered and, ideally, reflected in the paper? If
not, could you elaborate on what you are looking for? I believe Zach
feels that the question has been answered. I'd like to close the loop to
confirm that your question was correctly understood and that the answer
provided addresses it.
Tom.
On 7/11/23 11:28 AM, Tom Honermann via SG16 wrote:
>
> For clarity, the reason that SG16 is copied on this thread stems from
> discussion in the 2023-03-22 SG6 meeting
> <https://github.com/sg16-unicode/sg16-meetings#march-22nd-2023> during
> review of P2728R0:
>
> * Hubert asked if the transcoding iterator hierarchy unpacking is
> exposed such that a programmer could take advantage of it.
> * Zach replied that he had not considered exposing it, but that
> doing so is a possibility that could be looked into.
> * Zach agreed that it would be useful to have generalized support
> for such unpacking.
>
> Zach proceeded to expose the unpacking feature in a later revision of
> the paper. The question, mostly to Hubert, is whether the exposure
> that Zach added satisfies Hubert's motivation for asking the question.
> Essentially, do we want to expose this (Unicode specific)
> functionality as described or, insist on generalizing this
> functionality if it is to be exposed, or leave the unpacking mechanism
> as unspecified implementation-detail (but with the unpacking behavior
> still specified in prose).
>
> Tom.
>
> On 7/11/23 10:47 AM, Inbal Levi via SG16 wrote:
>> Thanks for the clarification, Zach!
>>
>> To be more accurate - for the Unicode proposal, we talked about
>> having a Unicode-specific implementation (renamed, as suggested).
>> But one possible implementation is to have a general one, with a
>> specialization for Unicode (or forwarding to the specific one), so
>> I'm still interested to know if there's an appetite/interest in a
>> (possibly) general utility :)
>>
>>
>> Best Regards,
>> Inbal Levi
>>
>> ISO C++ LEWG Co-Chair, SG9 Chair & Israeli NB Chair
>> C++Now Program Chair & CoreC++ Conference Organizer
>>
>>
>> On Tue, 11 Jul 2023 at 17:35, Zach Laine
>> <whatwasthataddress_at_[hidden]> wrote:
>>
>> I don't think we had much support for moving
>> unpack_iterator_and_sentinel out of std::uc (it's 100%
>> Unicode-specific, and as Tomasz pointed out would be *very* difficult
>> to make interoperable with anything else). However, we did discuss
>> that it should get some Unicodiness in its name -- maybe be adding
>> "utf" in there or similar.
>>
>> Zach
>>
>> On Tue, Jul 11, 2023 at 9:31 AM Inbal Levi <sinbal2l_at_[hidden]>
>> wrote:
>> >
>> > Hello all,
>> > Minutes from the latest SG9 meeting appear here:
>> https://wiki.edg.com/bin/view/Wg21telecons2023/P2728
>> >
>> > During the meeting, we've discussed P2728R5, and considered
>> having the following two utils from the paper ported into the
>> rangers namespace (names are tentative):
>> >
>> > borrowerd_transform_view (similar to transform_view, but able
>> to extend the lifetime of the underline thing)
>> > unpack_iterator_and_sentinel(ranges::begin(base_,
>> ranges::end(base_)) (able to "strip" unnecessary wrapping, to
>> improve performance)
>> >
>> > (Tomasz/Zach will send a mail thread with the details of the
>> proposed to the SG9 reflector)
>> > I would love the group's input on this direction. CCing SG16,
>> as I understood this was brought up there as well.
>> >
>> > Thanks all for joining and for the great feedback!
>> >
>> > Best Regards,
>> > Inbal Levi
>> >
>> > ISO C++ LEWG Co-Chair, SG9 Chair & Israeli NB Chair
>> > C++Now Program Chair & CoreC++ Conference Organizer
>> >
>> >
>> > On Mon, 10 Jul 2023 at 17:20, Zach Laine
>> <whatwasthataddress_at_[hidden]> wrote:
>> >>
>> >> The latest revision is here:
>> https://isocpp.org/files/papers/P2728R5.html
>> >>
>> >> Zach
>> >>
>> >> On Mon, Jul 10, 2023 at 7:08 AM Inbal Levi
>> <sinbal2l_at_[hidden]> wrote:
>> >> >
>> >> > Hello all,
>> >> > I apologize for the late mail. As discussed in Varna, today
>> we will continue reviewing the paper by Zach (9:30 Pacific, as
>> usual):
>> >> >
>> >> > (Tentative) P2728R3: Unicode in the Library, Part 1: UTF
>> Transcoding
>> >> >
>> >> > Meeting link:
>> https://iso.zoom.us/j/94426994719?pwd=WnhNYVdvYWNrUzcvNEZPbStySTh6dz09
>> >> > Password: as usual (please email me if you're unsure)
>> >> >
>> >> > See you soon!
>> >> > Best Regards,
>> >> > Inbal Levi
>> >> >
>> >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> >> > Lead Software Engineer @ Millenium
>> >> > Isocpp, Boost &"Hamakor" Non-Profits Board Member
>> >> > ISO C++ LEWG Co-Chair, SG9 Chair & Israeli NB Chair
>> >> > C++Now Program Chair & CoreC++ Conference Organizer
>> >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>>
>
transcoding iterator hierarchy unpacking? Do you feel that your question
has been adequately answered and, ideally, reflected in the paper? If
not, could you elaborate on what you are looking for? I believe Zach
feels that the question has been answered. I'd like to close the loop to
confirm that your question was correctly understood and that the answer
provided addresses it.
Tom.
On 7/11/23 11:28 AM, Tom Honermann via SG16 wrote:
>
> For clarity, the reason that SG16 is copied on this thread stems from
> discussion in the 2023-03-22 SG6 meeting
> <https://github.com/sg16-unicode/sg16-meetings#march-22nd-2023> during
> review of P2728R0:
>
> * Hubert asked if the transcoding iterator hierarchy unpacking is
> exposed such that a programmer could take advantage of it.
> * Zach replied that he had not considered exposing it, but that
> doing so is a possibility that could be looked into.
> * Zach agreed that it would be useful to have generalized support
> for such unpacking.
>
> Zach proceeded to expose the unpacking feature in a later revision of
> the paper. The question, mostly to Hubert, is whether the exposure
> that Zach added satisfies Hubert's motivation for asking the question.
> Essentially, do we want to expose this (Unicode specific)
> functionality as described or, insist on generalizing this
> functionality if it is to be exposed, or leave the unpacking mechanism
> as unspecified implementation-detail (but with the unpacking behavior
> still specified in prose).
>
> Tom.
>
> On 7/11/23 10:47 AM, Inbal Levi via SG16 wrote:
>> Thanks for the clarification, Zach!
>>
>> To be more accurate - for the Unicode proposal, we talked about
>> having a Unicode-specific implementation (renamed, as suggested).
>> But one possible implementation is to have a general one, with a
>> specialization for Unicode (or forwarding to the specific one), so
>> I'm still interested to know if there's an appetite/interest in a
>> (possibly) general utility :)
>>
>>
>> Best Regards,
>> Inbal Levi
>>
>> ISO C++ LEWG Co-Chair, SG9 Chair & Israeli NB Chair
>> C++Now Program Chair & CoreC++ Conference Organizer
>>
>>
>> On Tue, 11 Jul 2023 at 17:35, Zach Laine
>> <whatwasthataddress_at_[hidden]> wrote:
>>
>> I don't think we had much support for moving
>> unpack_iterator_and_sentinel out of std::uc (it's 100%
>> Unicode-specific, and as Tomasz pointed out would be *very* difficult
>> to make interoperable with anything else). However, we did discuss
>> that it should get some Unicodiness in its name -- maybe be adding
>> "utf" in there or similar.
>>
>> Zach
>>
>> On Tue, Jul 11, 2023 at 9:31 AM Inbal Levi <sinbal2l_at_[hidden]>
>> wrote:
>> >
>> > Hello all,
>> > Minutes from the latest SG9 meeting appear here:
>> https://wiki.edg.com/bin/view/Wg21telecons2023/P2728
>> >
>> > During the meeting, we've discussed P2728R5, and considered
>> having the following two utils from the paper ported into the
>> rangers namespace (names are tentative):
>> >
>> > borrowerd_transform_view (similar to transform_view, but able
>> to extend the lifetime of the underline thing)
>> > unpack_iterator_and_sentinel(ranges::begin(base_,
>> ranges::end(base_)) (able to "strip" unnecessary wrapping, to
>> improve performance)
>> >
>> > (Tomasz/Zach will send a mail thread with the details of the
>> proposed to the SG9 reflector)
>> > I would love the group's input on this direction. CCing SG16,
>> as I understood this was brought up there as well.
>> >
>> > Thanks all for joining and for the great feedback!
>> >
>> > Best Regards,
>> > Inbal Levi
>> >
>> > ISO C++ LEWG Co-Chair, SG9 Chair & Israeli NB Chair
>> > C++Now Program Chair & CoreC++ Conference Organizer
>> >
>> >
>> > On Mon, 10 Jul 2023 at 17:20, Zach Laine
>> <whatwasthataddress_at_[hidden]> wrote:
>> >>
>> >> The latest revision is here:
>> https://isocpp.org/files/papers/P2728R5.html
>> >>
>> >> Zach
>> >>
>> >> On Mon, Jul 10, 2023 at 7:08 AM Inbal Levi
>> <sinbal2l_at_[hidden]> wrote:
>> >> >
>> >> > Hello all,
>> >> > I apologize for the late mail. As discussed in Varna, today
>> we will continue reviewing the paper by Zach (9:30 Pacific, as
>> usual):
>> >> >
>> >> > (Tentative) P2728R3: Unicode in the Library, Part 1: UTF
>> Transcoding
>> >> >
>> >> > Meeting link:
>> https://iso.zoom.us/j/94426994719?pwd=WnhNYVdvYWNrUzcvNEZPbStySTh6dz09
>> >> > Password: as usual (please email me if you're unsure)
>> >> >
>> >> > See you soon!
>> >> > Best Regards,
>> >> > Inbal Levi
>> >> >
>> >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> >> > Lead Software Engineer @ Millenium
>> >> > Isocpp, Boost &"Hamakor" Non-Profits Board Member
>> >> > ISO C++ LEWG Co-Chair, SG9 Chair & Israeli NB Chair
>> >> > C++Now Program Chair & CoreC++ Conference Organizer
>> >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>>
>
Received on 2023-08-14 17:09:58