Oh yeah. Then fmt author and all its simps like you went to my project to
attack me oh yeah. He is doing that on twitter again.

On Mon, Sep 4, 2023 at 11:28 AM coshvji cujmlqef <oyzawqgcfc_at_[hidden]>
wrote:

> 1. LOL. I did not reply you privately deliberately. Reply to the wrong
> person.
>
> I use abortion clinics to explain to you what is historical materialism.
> Human history never changes because of certain individuals (like Donald
> Trump) did something great. That is called history of great man. History
> changes because there are material changes beneath it.
>
> https://www.youtube.com/watch?v=QjsDIoyTX_0
> The fact is that rising rate of violence against abortion clinics are the
> fundemental reason why Roe V Wade is overturned. If this keeps happening,
> it would finally reach a point abortions will be banned nationwide.
> Probably spread to other nations as well in the future. From historical
> perspective, abortion will be banned because more and more abortions
> clinics are bombed.
>
> 2. Same thing here: I do not see how WG21 is going to change when it is
> filled with big corporations.
> You could say i am unhinged. TBH, i do not care at all. However, I do not
> think i am the first one who disagrees with iostream and format string
> fundamentally. But they had been long historically ignored.
>
> What about breaking ABIs? Oh, large companies have 40 years old binary
> that loses source code that "cannot break". Why should I care about their
> projects? See only kill those companies would fix the problem.
>
> What about giving up EBCDIC? Or at least making the situation better? Oh
> no. WG21 does nothing.
>
> Oh, we also have new format string advocators in WG21, hmhm. Of course
> they are going to push propaganda to advocate format string which are
> historically vulnerablities. "These big companies love format string lol
> because they want their programmers to write cheap and buggy code." Then
> went there talking shit like: C++ is dangerous and only terroists use it
> because it helps CCP violates human rights.
>
> On Mon, Sep 4, 2023 at 11:13 AM Jonathan Wakely via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>>
>>
>> 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
>>>>>
>>>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>