Hello Nico, all,
Nico - since this was sent from SG9 in the past I get your point, but I can
guarantee (as SG9 chair) that SG9 has no preference as a group, other than
improving range facilities (quite a lot of them are mentioned in the thanks
section of your paper). :)
My intention was not to block it but to make sure it gets processed before
moving it to LEWG. In any case, I'm adding (a bit late, unfortunately) SG16
and other relevant parties.

*~~~~~~~~~~~~~~~~~*

To summarize the suggestions and open topics (Nico - please fix if not
accurate):

   1. The expression views::istream<T>(E) is expression-equivalent to
   istream_view<T>{E}.
   2. *For `mywstream` wchar_t strings:* ((),{} eq as in 1)
   `std::ranges::istream_view<int>(mywstream)` will no longer compile and
   needs to be changed to:
   `std::ranges::wistream_view<int>{mywstream}` or
   `std::views::istream<int>(mywstream)`
   *For `myustream` UTF strings:*
   `std::ranges::istream_view<int>(ustream))` will no longer compile and
   needs to be changed to:
   `std::ranges::basic_istream_view<int, char8_t>(ustream))` or
   `std::views::istream<int>(ustream))`
   3. Do we want to have full support for all character types? (Maybe in a
   different proposal. Current proposal only contains: istream_view and
   wistream_view)

Paper mentions istream_view usage, attaching attempts to collect (very
broad, non committing) numbers:

   - *Github projects*: (359 code results)
   https://github.com/search?l=C%2B%2B&q=ranges%3A%3Aistream_view&type=Code
   - *Codesearch*: (0 results)
   https://codesearch.isocpp.org/cgi-bin/cgi_ppsearch?q=ranges%3A%3Aistream_view&search=Search

   - *Google open source*: (0 results)
   https://cs.opensource.google/search?q=ranges::istream_view

~~~~~~~~~~~~~

*SG16 - We will be happy for quick feedback, if possible.*
*Roger - If you can find the NB comment and send it, that would be great.*

*We will be happy to have attendees from SG16, SG9 at
today's telecon. (LEWG is scheduled for today, 10:00 Pacific)*

Best regards,
Inbal Levi

On Sat, 28 Aug 2021 at 18:36, Nico Josuttis <nico_at_[hidden]> wrote:

> Thanks,
>
> IMO, it should go directly to LEWG.
> SG9 wants to have this API (although it creates inconsistencies even
> within the ranges library).
>
> But we break a fundamental 30 year old principle of the library as a whole
> for streams and strings.
> That is no longer an issue for SG9 (although I would prefer if SG9 would
> care for overall library principles).
>
> As it is a defect against C++20, we should also be fast.
>
> Thanks and best
> Nico
>
>
> Am 28. August 2021 17:21:32 MESZ schrieb Inbal Levi <sinbal2l_at_[hidden]>:
>>
>> Hi all,
>> First, thank you Nicolai for bringing this up, and everyone for your
>> informative comments and inputs.
>> Casy is right to say this was already considered as part of P1035.
>> Nevertheless, considering Roger's comment, it might be the case that we
>> missed something in the process.
>> I believe we should at least have a discussion - I'll consult library
>> evolution chairs and see if this should be scheduled to SG9 first or go
>> directly to LEWG.
>>
>> Thanks!
>> Inbal
>>
>> On Fri, 27 Aug 2021 at 12:29, Nicolai Josuttis via Lib-Ext <
>> lib-ext_at_[hidden]> wrote:
>>
>>> Casey,
>>> with all respect,
>>>
>>> do you honestly say that we never should fix bugs when we find them
>>> after we shipped a standard?
>>>
>>> So, you also voted against adopting the following defects against C++20
>>> in June?
>>> P2328R1
>>> P2325R3
>>> P2210R2
>>> which all BREAK even behavior of ranges so that the same code now may
>>> produce different results.
>>>
>>> If you didn't, why is THIS paper more severe than those?
>>> It is backward compatible for the major use case and creates a compiler
>>> error for all other cases.
>>> Compared to the other changes that is really small.
>>>
>>> Please note that NOW is the FIRST time others than the usual range
>>> experts can play and use ranges in practice having a full implementation
>>> available that reveals all the problems that were standardized.
>>> How could you accept that ranges become part of C++20 knowing that what
>>> we standardized was NEVER fully implemented and expect that there are no
>>> bugs to fix?
>>> And it will still take a while, because ranges are complex and we
>>> therefore have many flaws.
>>>
>>> And finally:
>>> Do you really prefer confusion and chaos for the next 20 years better
>>> than a mature and consistent design before programmers start to use it?
>>>
>>> The simple fact is: ranges are not done yet.
>>> We now hopefully find and fix all the broken details.
>>> And it will for sure still take a while.
>>> (I also really wished this would not be necessary and the ranges library
>>> would have been in a better shape).
>>>
>>> Thanks and best
>>> Nico
>>>
>>>
>>> Am 26.08.2021 um 23:19 schrieb Ville Voutilainen via SG9:
>>> > On Fri, 27 Aug 2021 at 00:02, Casey Carter <cartec69_at_[hidden]> wrote:
>>> >>> 1) when there's a meow and a basic_meow in C++, basic_meow is a
>>> >>> template, and meow is an alias of a specialization
>>> >>> 2) when there's a meow_view in ranges, meow() is the view factory
>>> that
>>> >>> produces such a view.
>>> >>>
>>> >>> basic_istream_view and istream_view() conflict with both of those
>>> >>> conventions.
>>> >>
>>> >>
>>> >> One person's "this conflicts with both of those conventions" is
>>> another's "this is the counter-example that proves there are no such
>>> conventions." We're not discussing a proposal to add basic_istream_view and
>>> istream_view to C++, they are the status quo. The authors of P1035 didn't
>>> trick LEWG by making a istream_view an alias that we changed to a function
>>> at the last minute in LWG - this is all intentional design that was
>>> discussed and approved by LEWG.
>>> >
>>> > There was a convention, but now that we added things that break the
>>> > convention, the convention no longer exists. Does that sound
>>> > like a circular argument to you? :)
>>> >
>>> >>> The "55 weeks" argument doesn't work either. We made breaking changes
>>> >>> to ranges when they had 'sailed' approximately
>>> >>> 45 weeks ago, so I find it rather arbitrary how a couple months'
>>> worth
>>> >>> more somehow makes this convention-breaker
>>> >>> in the standard something that we can't discuss.
>>> >> There's nothing we can't discuss. I didn't forbid anyone to discuss
>>> it, and I doubt anyone would care if I tried to do so. I am simply pointing
>>> out that it's too late to propose a change to a Standard that we shipped
>>> more than a year ago. I've been shipping istream_view for six months. It
>>> will take WG21 at least that long again to approve this proposal, and at
>>> best a month or two to ship the change once it's approved. To me, breaking
>>> code that users have been writing for more than a year requires a stronger
>>> justification than "we changed our mind."
>>> >
>>> > Sure. We have broken things that have been shipping for a decade, so
>>> > the mere amount of time is not a very good argument.
>>> > How much code would this proposal really break? For users of istreams
>>> > of char, it sure looks like it might be "not much".
>>> >
>>> > On the other hand, we _do_ have an option that breaks no code (within
>>> > our expectations stated in that standing document
>>> > that says "we reserve the right to add..."). We could add
>>> > basic_inputstream_view, inputstream_view, and inputstream().
>>> > And some wide-character versions for those who care about them.
>>> >
>>> >> If people think that three years isn't enough time to finish
>>> reviewing a new Standard, maybe we should be proposing to change the length
>>> of the cycle?
>>> >
>>> > I'm not convinced that's the logical outcome of a single naming
>>> > problem in the lake of ranges and views, which themselves are a puddle
>>> > next to an actual ocean that is a whole standard.
>>> >
>>>
>>> --
>>> Nicolai M. Josuttis
>>> www.josuttis.de
>>> +49 (0)531 / 129 88 86
>>> +49 (0)700 / JOSUTTIS
>>>
>>> Books:
>>> C++: http://cppstdlib.com, http://cppstd17.com,
>>> http://tmplbook.com, http://cppmove.com
>>> SOA: http://soa-in-practice.com
>>>
>>> _______________________________________________
>>> Lib-Ext mailing list
>>> Lib-Ext_at_[hidden]
>>> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext
>>> Link to this post: http://lists.isocpp.org/lib-ext/2021/08/19658.php
>>>
>> --
> Nico Josuttis
> (sent from my mobile phone)
>