ThePhD

My problem is that if you're an actual C superset, you're carrying a lot of baggage that will permanently compromise the best case of what you can ever become.

These days, with C standards back on a regular cadence, the thing you have to be a superset of is also a moving target, and you have to make sure your extensions don't end up incompatible with future C changes. If you succeed enough, the C standard has to be worried about compatibility with you in return.

Even the most conservative C supersets like non-standard GNU C have created friction for what the actual ISO standard can do in future, including the highly demanded addition of nested functions [1]. One could almost argue that the long-term value of that C superset will be net-negative precisely because it was successful enough to become a permanent interoperability hazard for C itself. (They could have avoided that by not claiming to be C at build time, but that would have also avoided anyone ever using it, just like almost all of the other supersets).

C++ isn't even a C superset and still that relationship creates friction both ways [2].

Now if you're not a C superset, you have a more difficult adoption story and that is enough to kill a language before it ever has a chance. Even so, far more languages have succeeded by tackling interoperability problems than by being supersets.

Rust has a fair amount of friction binding to C, but people see enough value in overcoming that; and part of what people claim to…

> I think most C programmers frustrations with UB stem from knowing that the C standard has fundamental flaws and modern compilers abuse that fact for "optimizations" on UB

Do they actually know that? I don't think so. Let's take [0] for instance (the author is an expreienced C programmer who loves the language and wrote a re-implementation of bc in it):

There seemed to be a lot of misunderstandings; I could not get a handle on what this person thought UB meant. I finally figured it out: this person’s definition of UB was not “the language spec can’t guarantee anything.” Instead, it was “compilers can assume UB does not exist and optimize accordingly.” Wat. Yep. Apparently, that was news to him, even though C implementations have been behaving like that for about 30 years already, and you can read the rest of the post for the "this is evil, we the users must do something about it" take. And the proposed "something" is not "we should instead use a language with actually defined semantics", oh no. It's "use compiler flags to force more reasonable behaviour, hopefully" and "somebody should write boringcc, unfortunately, I am myself a bit too busy for that". Well, despite numerous pleas and several attempts, nobody has managed to write boringcc which is telling of something, I'm just not sure of what exactly. So... I think it is about imprinting: "Oh, it's a wonderful language, well, it would be if it was actually implemented the way I used to think it is…

> everybody could (and should?) just start declaring size parameters before their respective buffer parameters in new code

I know that was a common opinion pre-C23, but it feels like the committee trying to reshape the world to their desires (and their designs). It's a longstanding convention that C APIs accept (address, length) pairs in that order. So changing that will already get you a score of -4 on the Hard to Misuse List[1], for "Follow common convention and you'll get it wrong". (The sole old exception in the standard is the signature of main(), but that's somewhat vindicated by the fact that nobody really needs to call main(); there is a new exception in the standard in the form of Meneide's conversion APIs[2], which I seriously dislike for that reason.)

The reason I was asking is that 'uecker said it was requested at the committee draft stage for C23 by some of the national standards orgs. That's already ancient history of course, but I hoped the idea itself was still alive, specifically because I don't want to end up in the world where half of C APIs are (address, length) and half are (length, address), when the former is one of the few C conventions most everyone agrees on currently.

[1] https://ozlabs.org/~rusty/index.cgi/tech/2008-04-01.html

[2] https://thephd.dev/_vendor/future_cxx/papers/C%20-%20Restartable%20and%20Non-Restartable%20Character%20Functions%20for%20Efficient%20Conversions.html

I can indeed "quite easily" hack this up. But this is C++, and C++ string manipulation is infamously unsafe and error-prone, and I really have very little desire to hack this up, write tests, etc, when I'd rather not think about UTF-8 at all.

For an example of how unsafe and error-prone C++ string manipulation is, from simdutf's very own documentation:

> simdutf_warn_unused size_t convert_latin1_to_utf8(const char * input, size_t length, char* utf8_output) noexcept;

Eww, this literally cannot be safe in the sense of "free from memory-safety errors when called carelessly" (like Rust or almost any GC language would expect). Look, takes a single pointer to an output array with no length or other limit. It overruns the buffer unless you get it exactly right. (ThePhD has a very on-point rant or two [0] about this, and ztd.text IMO (and in his opinion) gets this right.) Also, for all that simdutf is really quite fast, it's really not obvious how to transcode latin-1 to utf-8 in a single pass, because you apparently need to compute the length first.

I think one of the great strengths of safer languages is that they fight back when you try to design an API like this.

[0] https://thephd.dev/output-ranges

It's possible, but those weren't mentioned unless I missed something. The keynote was "start of the day, shared slot with somebody else, 30 minutes".[1] No mention of different length after the change, but I would assume it will mean a different timeslot.

I think what happened is just the regular chaos and hub-hub that's involved with organising these things; since JeanHeyd himself already indicated he wasn't sure he wanted to give keynote the organisers probably figured it didn't matter much to him. Classic expectation mismatch. For reasons that are not entirely clear to me JeanHeyd assumed "somebody is pulling very weird strings behind the scenes", "shadowy decisions that are non-transparent", and "vindictive behavior". The best explanation I can come up with for that is that this is not so much about this talk, but rather expressing general unhappiness with the Rust leadership, and this is merely the "the final straw". But who knows...

[1]: https://thephd.dev/i-am-no-longer-speaking-at-rustconf-2023

I'm sure legacy C and C++ will be around for a long time, but their process for authoring new standards also seems somewhat unsustainable.

It seems like people making contributions to the C and C++ standards are also at risk of getting burnt out: https://thephd.dev/finally-embed-in-c23

> It was all worth it.

> …

> Or. That’s what I keep telling myself. Because it doesn’t feel like it was worth it. It feels like I wasted a lot of my life achieving something so ridiculously basic that it’s almost laughable. How utterly worthless I must consider myself, that hearing someone complain about putting data in C++ 5 years ago put me on the track to decide to try to put something in a programming language standard. That I had to fight this hard for table scraps off the Great C Standard’s table.

> What a life, huh?