Why is iostream omitted instead of simply making it freestanding? Well, it
relies on locale, and this reliance tends to increase its size
significantly. To be frank, it can be considered a design failure.

>From my perspective, I fail to see any valid reason why IO cannot be
freestanding if it's designed correctly. In fact, I find it to be a less
challenging task compared to making dynamic memory freestanding.

Incidentally, why do you consider it acceptable to have three APIs
essentially performing the same task? Let's take the networking proposal as
an example. Both the ipv4 and ipv6 classes feature three functionalities
that serve identical purposes: the to_string method, iostream overloads,
and a formatter. First and foremost, it's worth noting that none of these
options are particularly efficient, primarily due to the creation of
std::string. Secondly, why is the issue of API duplication being
overlooked? It's reminiscent of the situation with std::filesystem, where
we have both error code and exceptions serving as dual APIs. However, in
this case, it appears to be even more problematic. Why can't we aim for an
API that's not only fast and versatile but also directly applicable for
both I/O and string operations? It's worth mentioning that this approach
doesn't lend itself well to the implementation of third-party libraries,
such as QString or other languages' string types like PyObject, which are
not freestanding either.

"That's not a proposal. In fact, nothing you ever suggest is a proposal,
just ranting. You have very little credibility on any C++ topic as far as
I'm concerned."

I have earned the trust and credibility of many individuals. However, you
seem to disregard this fact and choose to criticize me in this context. I
align with the scientific perspective by consistently adhering to the
historical materialist viewpoint, which is rooted in the principles of
scientific understanding.

On Mon, Sep 4, 2023 at 5:35 AM Jonathan Wakely via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
>
> On Mon, 4 Sept 2023, 02:31 unlvsur unlvsur via Std-Proposals, <
> std-proposals_at_[hidden]> wrote:
>
>> Absolutely, QtCore! I contend that the root of this predicament can be
>> traced back to the calamity that is iostream. Why is there a need for Qt to
>> reinvent QFile? The core issue lies in the undeniable fact that iostream
>> has proven itself to be a resounding failure, forcing people to actively
>> seek out alternatives.
>>
>>
>>
>> Here's the crux of the matter: It appears nigh impossible to introduce
>> any new functionality without being ensnared by iostream's inherent
>> shortcomings. Take, for instance, the endeavor to incorporate a "linear
>> algebra" library. It inevitably leads to the tangled web of operator
>> overloading for iostreams, a necessity just to output your matrix.
>> Additionally, I require this linear algebra to be freestanding; otherwise,
>> it becomes utterly unusable. Clearly, iostream renders the situation
>> untenable for freestanding applications.
>>
>
> You do like to talk in absolutes, even when you're out of your depth and
> wrong.
>
> Where in P1673 or P1385 (or P1166 or P1891) does it say the proposal
> depends on iostreams? Where are the operator overloads for outputting a
> matrix described? Can you explain why that iostreams functionality couldn't
> be omitted for freestanding implementations, leaving the rest supported,
> just like we did for the iostream-dependent parts of <iterator> and
> <ranges>? Are you just spouting rubbish without understanding the topic
> properly, as I've seen several times in the past whenever you wade in
> somewhere and start attacking people?
>
> There is an issue with <random> requiring iostreams, but the same
> "partially freestanding" principle applies there, it could all be optional.
> Somebody just needs to propose it and do the work to get it approved for
> the standard. That doesn't happen by being a blight on the C++ community
> and attacking the people who are actually trying to do that.
>
>
>
>
>>
>> My proposal stands: We should embrace an entirely new IO library, one
>> poised to supersede the current IO facilities. It's high time we consigned
>> std::locale, iostream, ctype.h, format, charconv, filesystem, and their ilk
>> to obsolescence. Failure to do so will merely perpetuate the complications
>> that accompany each new feature addition.
>>
>
> That's not a proposal. In fact, nothing you ever suggest is a proposal,
> just ranting. You have very little credibility on any C++ topic as far as
> I'm concerned.
>
>
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>