On Mon, 4 Sept 2023 at 15:46, Jonathan Wakely <cxx_at_[hidden]> wrote:

>
>
> On Mon, 4 Sept 2023 at 14:49, coshvji cujmlqef <oyzawqgcfc_at_[hidden]>
> wrote:
>
>> 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.
>>
>
> So since you've pivoted to "why isn't I/O freestanding anyway?" I assume
> that's your twisted way of admitting you're completely wrong about linear
> algebra being held back by iostreams?
>
> Nice attempt at deflection, but you're still wrong.
>
>
>>
>> Incidentally, why do you consider it acceptable to have three APIs
>> essentially performing the same task?
>>
>
> Ah, more deflection that has nothing to do with the topic of allocator
> being freestanding. You're just ranting again.
>
>
>> 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.
>>
>
>
> So why do you keep being banned/muted in various communities? Funny how
> that doesn't happen to other credible people.
>
>
>
>> 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.
>>
>
>
> That doesn't excuse you acting like an entitled brat and abusing people
> for not doing what you want.
>
> I'm sick of you attacking and abusing members of WG21 for not following
> all your suggestions. Stop acting like a child.
>
> For anybody who thinks I'm overreacting, I've been putting up with this
> clown for years, including things like "DEATH TO WG21":
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100057#c36
>

Now he's mailing me privately, off-list, with something about abortion
clinics, violent revolution to fix WG21's disgusting interests.

He's unhinged.




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