Björkus "No time_t to Die" DorkusMy brilliant idea for "any VLA type" was thwarted because of the stupid rules for array declarators in parameters goddamn I hate that language rule soooooooo much.
Sarah@thephd who is the ruler of the rules though, hm? Would it be perhaps you who proposes language features?
@thephd if you're being brilliant and the language is stopping you, clearly just change the language to allow you and everyone else to thrive
@gaycodegal Alas, backwards compatibility 😔
Alex Celeste, Princess Consort of BurnoutC99 already had the option to make
void f(int[6]);
mean something distinct from
void f(int *);
void f(int[60]);
and decided that the backwards compatibility case for people writing in a constant number but not really meaning it, was more compelling than turning obviously-wrong declarations into errors
instead you need a new keyword (that is widely misunderstood and hated) if you want it to even be eligible for a warning
(in WG14's defence we more or less agreed "morally" to fix this per a proposal by @uecker but didn't get to it in the C23 cycle)
@erisceleste @gaycodegal @uecker Good ol' ancestors not saving us by choosing compat over boldness. Same situation where everyone complained to me about nullptr in C. But, when we had proposals before to mandate #define NULL (void*)0, to prevent the issues that obviously came up with ... functions and similar conceptual problems with not-exactly-constant-zero being used to initialize a pointer, they all got weak in the knees and rejected it.
So now, you have to do the "well, we have to simplify the situation by adding something new". And then people get all pissy when if they had ever put in the work to make 0 a less attractive option for the null pointer, or done even a deprecation 20 years ago we'd have a leg to stand on and a reason to fight for something today.
But they didn't.
So we don't.
@erisceleste @gaycodegal @uecker Call K&R whatever you want, but they were so on-the-ball with understanding that people in the future deserved better. They nuked-from-orbit the literal function declaration and definition syntax that had their name on it — from the very first standard version of C — by putting it in deprecated.
They understood it was better to look to the future rather than endlessly cling to what had been.
I wish people who worked with C today were even a smidgen as brave as those two.
Eniko (moved ➡ gamedev.place)@thephd @erisceleste @gaycodegal @uecker posts like this makes me wonder how feasible it would be to like. fork C. and turn it into a new C-like language unencumbered by historical artifacts
and before anyone brings up C++: no not like that
so C is often called "mistakenly called simple", but there is a simple language in there struggling to get out of the 600-page spec
the hard part is a) getting agreement on the useful parts; and b) getting people to adopt your subset; and then c) gaining enough traction with your subset that anyone will touch new features
(like if it was up to me id take a flamethrower to floating point in its entirety and put it in an entire separate document, with the core language only saying "there is a tower of reals that have distinct types" such that you can define that float is separate from int but not otherwise how, beyond size/alignment/promote-rank
everybody is probably glad this sort of thing isn't up to me 😅)
if you make your subset minimal enough and associate it with a use case - say cough a specific virtual console or machine? - you might find adoption is a lot easier
but anyway C99 is the story of how evolution attempts can falter
@eniko
also if you try to fix things like pointers - which are simple and complex at the same time, but the simplicity isn't all good - you can very easily get to the point where it's not worth marketing the language as C* any more
(id love a small language that restricts pointer/ref usage even beyond what Rust does, but ... not sure how wide the demographic for it actually is)
arclight@erisceleste @eniko I'd put 90% of Fortran's math functions into a standard library, revise string handling and move it to a library, add enums, contracts, and type constraints (and maybe posits https://en.m.wikipedia.org/wiki/Unum_(number_format) ), and devote 2-3 standard libraries just to physical and numerical constants, all date-stamped and validated. Overhaul the OO syntax if not the whole model. Take a flamethrower to any remaining undefined behavior. Something low-magic with speed and simplicity and first-class features that focus on correctness, accuracy, and safety. 1-indexing stays.
Martin Uecker@erisceleste @eniko The actual language (excluding library) is about 180 pages.
And I like to point out that there is no agreement what it evens means to "fix" C. I think that some of the stuff we added in C23 (in the name of "fixing C") makes it worse and adds a substantial amount of complexity. I could point to many new GCC bugs or substantial additional complexity in the implementation.
I also like C very much how it is - more than C++ or Rust. I think compilers need to improve though.
@erisceleste @eniko What would make the world a better place if we had a rule that anybody who wants to add a feature to C has to fix one bug in GCC per sentence added to the standard.