Also why can we not get better syntax for C? Function pointer syntax is so bad that people actively avoid using them. #pragma once is a hack. Every string library function is actively dangerous in addition to puts/gets.
I know that nobody wants to be the one to mess with the core language and ruin it but this is awfully low-hanging fruit that hasn’t been fixed in 50 years.
For a different language syntax it makes a lot more sense to consider using a different language in the first place though, because everybody has a different opinion what such a 'better C' syntax should look like (e.g. it sounds like you'd actually want Zig).
Backwards compatability.
>Function pointer syntax is so bad that people actively avoid using them.
That is because C syntax mistakenly put the return value before the parameters. You use function pointers if you have to.
>#pragma once is a hack.
It is a hack to prevent the previous hack of #ifdef'ing the thing.
>but this is awfully low-hanging fruit that hasn’t been fixed in 50 years.
It is literally impossible to fix.
I recently submitted a PR for the `c2nim` import tool to handle double function pointers. I didn't actually understand the C code until I got the transpiler working despite cdecl.org:
// posix signal
void(*signal(int, void (*)(int)))(int);
var signal*: proc (a1: cint; a2: proc (a1: cint)): proc (a1: cint)
https://github.com/nim-lang/c2nim/blob/11f2c5363dfe7e8c7c8ce...
The other annoying one is that "signed" and "unsigned" are basically adjectives, but "long" can be both a type and a modifier. So it's difficult to parse unless you're the target C compiler. Technically you can, but you have to use backtracking.
var signal*: proc (a1: cint; a2: proc (a1: cint)): proc (a1: cint)
Variable signal is a pointer to a function that that takes two arguments (an int, and a function that takes an int), and returns a function that takes one argument (an int).
Of course, I'm assuming my interpretation is correct... perhaps it's not ;)
Note that Nim uses "*" as a public symbol sigil not a pointer. Its a bit odd at first coming from C but is nice and consistent.
var signal*: (cint,(cint)->void) -> (cint)->voidSeems like a good thing to be honest.
But actually I'd suggest the opposite of disallowing "long long" and making it like signed/unsiged as purely a modifier.
Long long is not even a 64 bit integer type, it’s a int_least64_t. Could be 128 or 256 bits for all you know.
As a generalization I completely disagree. But for function pointers specifically, yes, they are easily the worst part of the C syntax.
>void(signal(int, void ()(int)))(int);
That's just declaring signal as function (int, pointer to function (int) returning void) returning pointer to function (int) returning void, DUH. Thank you cdecl.org
But notice how absolutely ugly it is that the final return type comes first, that is due to the C function signatures.
This is trivial to parse if you use spiral rule, humans or machine.
Not really. Just create a bit mask.
https://github.com/dlang/dmd/blob/master/compiler/src/dmd/cp...
Looks like there's only about ~388 lines of logic to the bitmask? haha your definition of difficult might not match mine. ;)
void(*signal(int, void (*)(int)))(int)
Parentheses go first in order of operations, so we evaluate this first:
(*signal(int, void (*)(int)))
signal(int, void (*)(int))
This function returns a pointer, that when dereferenced, can be called with an int, and returns void when doing so.
In layman's terms, we have a function "signal" that takes an int and a function pointer and returns a function pointer, and both function pointers are to a function that takes an int and returns void.
Is it easy? If you can read C expressions, it can be easy. But it is definitely tedious, and does not come out quickly--it violates the principle that you have <type> <variable name>; it is not what I would consider readable or good design. And it would be easier if types were consistently read in one direction (like Rust types).
I simply can't tell if we're not fixing this stuff out of laziness, out of fear, or because no one wants to admit that no one knows who's holding us back.
I don't think you really understand what C actually is. C basically does not compete as a programming language. On a UNIX like it is the language of the kernel and as such its quirks inevitably represent the quirks of the kernel, you use C if you want to talk to the kernel.
>Would it truly be that difficult to introduce a "fn" keyword?
Yes, literally impossible. Just look at the controversy of C23 removing the almost entirely unused K&R function declaration syntax.
Nothing good has come to anyone who started an argument with those words.
It can be made to function more like C with #![no_std]. However that is an even less than batteries included experience than C.
Rust is absolutely a C replacement.
Whether C heads want to use it is a more complicated question. But some are very much into it (e.g. Brian Cantrill).
> It can be made to function more like C with #![no_std]. However that is an even less than batteries included experience than C.
std assumes you have a heap and IO, which most C environments do.
no_std removes all that (leaving only libcore as baseline), however you can re-add a dependency on "alloc" to get allocations and most of the standard collections back (all but hashset and hashmap, because no secure RNG).
You can also / instead fill your needs with third-party crates more dedicated to restricted or freestanding environments, like heapless (https://crates.io/crates/heapless).
For example C's qsort lives in the standard library, whereas in Rust although [].sort() needs alloc, the [].sort_unstable() is a core feature!
str::split_once(['5', '7']) will split a string at the first digit 5 or 7... You need considerable work to do that in C, and doing it modifies the string. In Rust it's a core feature.
Of course Rust is relying on the fact that none of the machine code is emitted unless you use these features, indeed split_once is fully generic, the types used only come into existence because you called the function. So presumably this was not practical as the fundamental language for writing Unix fifty years ago.
I think we should avoid saying "replacement" in general because eliminating all lines of C isn't a goal worth pursuing, C doesn't need to die for Rust to succeed, and there's room enough in this world for a hundred safe systems languages fulfilling different niches. I think a lot of people feel attacked & invalidated by the idea of a "C replacement" that isn't C compatible, like we're telling them their skills are no longer necessary or valuable, which is untrue & leads to flamewars and misunderstandings.
(Of course some C projects could abuse the preprocessor in ways that make it infeasible to even replace a C function with a Rust equivalent, but that's incredibly rare. And Rust has macro facilities of its own.)
It's true that there is a path to integrating Rust into C projects and potentially replacing C in that project, I just see lots of threads on HN derailed by the statement "Rust is a C replacement", and I think using more nuanced language would help.
things.into_iter().skip(1).each(|wtf| { are_you_kidding(wtf) })?
map { do_something($ARG) } @things[1..$#things];[0] https://en.wikipedia.org/wiki/Safe_navigation_operator
[1] e.g. it doesn't have let..else, macros, raw-idents, complicated type signatures, turbofishes, ... which could make the code a lot weirder
If you read the perlvar perldoc (perldoc perlvar or https://perldoc.perl.org/perlvar), you will see it is the English form of $_. You just need to:
use English;Rust's #![no_std] mode corresponds to what C calls freestanding mode, and Rust is relatively unusual in many modern languages in actually designing some sort of freestanding mode.