-
Quote
Member access using . even for pointers
Convenient.QuoteRemoval of multiple declaration syntax
Only a single declaration is allowed per statement in C3:
int i, j; // ERROR
int a; // Fine
In conditionals, a special form of multiple declarations are allowed but each must then provide its type:
for (int i = 0, int j = 1; i < 10; i++, j++) { ... }
Why?QuoteGoto removed
goto is removed and replaced with labelled break and continue together with the nextcase statement that allows you to jump between cases in a switch statement.
Rationale: It is very difficult to make goto work well with defer and implicit unwrapping of optional results. It is not just making the compiler harder to write, but the code is harder to understand as well. The replacements together with defer cover many if not all usages of goto in regular code.
Thankyou to the authors for providing the rationale. I'm not involved in your group or the languages you are probably using as context, without this I'm clueless as to why you are doing many of your things.
I like C as a low-level language, ie closer to assembly. Goto is natural for that. I'm worried that it sounds like you are placing compiler author desires ahead of users; what are these desires? Higher optimisation levels? That's a difficult sell to many C users, it's not an absolute problem, there are lots of shades of grey.
I want to look more at this 'defer' feature, but I can't find much docs about it. Best I can do is this example but it doesn't explain things like order of defer executions (stack or queue?), what happens to variable scope, whether I can defer an entire block of code (instead of just one line), etc.
EDIT: removed my extra ideas, split into another post below. -
Always the same. Based on C.QuoteStay close to C - only change where there is a significant need.
Or when you're too lazy to write code that cleans up after itself.
-
I disagree with both you Kloonk AND the statements of the C3 authors
I hope that doesn't count as a double negative.
There is lots to C I like. Definitely lots I don't like either. I'm not sure if C3 really floats my boat.
I wonder what C3's use case and mindshare is? Narrowly in-operating-system programming mainly? Or broad inc micros? I can't find anything about that on the c3-lang.org site.
The C2 site mentions kernels & bootloaders. -
Split from my earlier post, these are not comments about C3 but just interesting to compare with the lang changes they have made.
Some things I've imagined up over the years whilst using C that I wish I had:
(Whales1) Make the struct keyword unnecessary when using structs.
Both options are annoying: having to write "struct" before every defintion (inc in function args) OR having to typedef every struct.
This change would be backwards compatible with 99% of code (only breaking those that use struct names as names for something else too). If you want to keep using "struct" keyword everywhere you still could, no wakkas.
(Whales2) Clamp down on a lot of the silliness you read being discussed about undefined behaviour.
Do what the programmer would expect to happen on a standard 2's complement machine with type sizes a multiple of 8 bits. Use the rule of "least astonishment". C is supposed to be easier than assembly, don't make it harder.
(Whales3) Require that ALL new arches/platforms adopt the same fixed definitions for the sizes of int, char, long, etc.
I already use uint32_t and co from <stdint.h> but standard funcs like printf("%d") then require much uglier writing to be platform portable.
eg printf("I have %"PRIu32" doges with %"PRIs64" coolness factor\n", dogcount, coolsum) is just a pain, even worse when you have many consecutive fields and less string inbetween.
(Whales4) Syntactic sugar: namespaces.
Implement just as an auto-prepending of function (and var?) names with the characters "namespacename::" and do nothing more. Also allow someone to strip these characters off again (ie skip the namespacename:: prefix when using the funcs) if they so desire.
Completely optional, breaks nothing. Worth trying just to see if it makes things easier or harder to deal with. Many people already prefix their lib's function names with "LibName_" anyway, it might be better or worse to make an option of a standard method, not sure.
(Whales5) Syntactic sugar: allow defining functions in a class-like syntax.
ALL it does is automatically modify them to add a "self" argument to their arg list. No new/delete/constructor/deconstructor/public-private-protecgted stuff, leave that to Cpp, just a bit of sugar to make things a little neater and happier.Code: [Select]struct something
{
f32 posx, posy;
char *name;
void *aux;
};
something::new(u32 id);
something::destroy();
something::recolour(u8 r, u8 g, u8 b);
Unlike C++ you wouldn't even need to expose all of the struct internals inside the header files, so editing the struct contents won't cause header files to change (which then won't trigger a recompile of absolutely everything). Eg this would be OK too:Code: [Select]struct something;
something::new(u32 id);
something::destroy();
something::recolour(u8 r, u8 g, u8 b);
(On the technical side: this is doable because then things don't need to know sizeof(struct) any more) -
I disagree with both you Kloonk AND the statements of the C3 authors
I hope that doesn't count as a double negative.
There is lots to C I like. Definitely lots I don't like either. I'm not sure if C3 really floats my boat.
I wonder what C3's use case and mindshare is? Narrowly in-operating-system programming mainly? Or broad inc micros? I can't find anything about that on the c3-lang.org site.
The C2 site mentions kernels & bootloaders.
I wonder if the adoption of these mutations sometimes comes from a project leader with certain pet-hates. But I see your point, a solution looking for a problem. -
Probably a few different pet hates combined, the site lists 3 authors.
Of course my pet hates are far superior
C (for better and for worse) has been shaped by the desires of many diverse groups, so it's hard and dangerous to claim you have improved it without taking into account a lot of diverse people's opinions OR intentionally stating that your modified version is for a narrower use case than the original. -
C (for better and for worse) has been shaped by the desires of many diverse groups, so it's hard and dangerous to claim you have improved it without taking into account a lot of diverse people's opinions OR intentionally stating that your modified version is for a narrower use case than the original.
yup, in my case I can publicly declare I my modified version is for my narrower use case than the original, that's why it's called "my-c"
I think c/89 and c/99 cannot be modified/improved too much if they have to serve diverse people's needs
-
https://c3-lang.org/
https://strlen.com/lobster/
See for yourself: https://ziglang.org/
You guys are throwing me back to when I was (happily) subscribed to "Computer Language" magazine!
Thank you!
-
You guys are throwing me back to when I was (happily) subscribed to "Computer Language" magazine!
Thank you!
There are constant newlang discussions elsewhere. Checkout https://lobste.rs and https://news.ycombinator.com/
I don't like newlangs because I want to give my programs the best chance of still compiling and running in 10 or more years time. C is not perfect, stuff still breaks, but it's better than most.
-
You guys are throwing me back to when I was (happily) subscribed to "Computer Language" magazine!
Thank you!
There are constant newlang discussions elsewhere. Checkout https://lobste.rs and https://news.ycombinator.com/
I don't like newlangs because I want to give my programs the best chance of still compiling and running in 10 or more years time. It's not perfect, stuff still breaks, but it's better than most.
Absolutely.
It's hard enough to re-acquaint the libs and deps, and then you've got some Martian language to deal with.
It's a mid-level language that everyone eventually wishes it were high level. -
You guys are throwing me back to when I was (happily) subscribed to "Computer Language" magazine!
Thank you!
was/is it interesting?
-
I don't like newlangs because I want to give my programs the best chance of still compiling and running in 10 or more years time.
LOL, like "Fire-fLOP" (aka firefox) ? In 2005 I was able to compile it on my PowerBook G4.
Now not only it's C++11 (requires modern gcc version) & Rust (requires llvm/clang) but building it eats more than 2GByte of ram
my old laptop has 512Mbyte of ram, was able to compile the early versions of FireFox but .. today I only compile Dillo instead, ssh-tunneling to a proxy that makes it access to HTTPs web 2.0.
Or, like the old Gentoo portage, that was python v1 && EAPI={1 , 2}?
Now it's Python >=3.*, EAPI={ 5 , 6 , 7 , 8}, no more compatible with previous ABI.Code: [Select]case ${EAPI} in----> forget your old Overlays, forget ***every*** single old portage: old stuff won't work on modern stuff.
5) ;;
6) ;;
7) ;;
8) ;;
*) die "EAPI=${EAPI} is not supported" ;;
esac
And I have no solution, except an ugly hybrid merge-up(1) for my old router (2008); while for the new one router (2020) ... I am all with 2023 stuff, and expect (hope?) it will work for the next 5-8 years.
Or, like Perl, autodoc (Latex?), and other scripts used in Linux Kernel?
can you still compile kernel 2.0? no -> need to be fixed, but you'd best use an old rootfs
can you still compile kernel 2.2? no -> need to be fixed, but you'd best use an old rootfs
can you still compile kernel 2.4? no -> need to be fixed, but you'd best use an old rootfs
Can you still compile kernel 2.6? no -> need to be fixed, but you'd best use an old rootfs
Can you still compile kernel 3.*? somehow yes, but ... it's full of pain, and you'd best use an old rootfs
So, I am afraid that it's not only the language but rather everything from the kernel up!
(1) basically it's still a 2008 stage4, integrated with a forced multi-library or static-linked (I know, it's wrong by design, and consumes more space ... but at least it works) to have some modern stuff on it, like modern OpenSSL, modern OpenSSH, modern curl, and modern wget, all able to work on "https" and SSL stuff. -
https://c3-lang.org/
https://strlen.com/lobster/
See for yourself: https://ziglang.org/
You guys are throwing me back to when I was (happily) subscribed to "Computer Language" magazine!
Thank you!
I have posted quite a few of these. These new programming languages make an almost endless list!
Most of the corresponding threads, the "yet another one" series I have started are more for a quick fun than anything else.
Many are sort of "funny", some are interesting. As I said previously, I think Zig would fit in the interesting category. Another one would be Odin.
The guy behind Odin, which is nicknamed gingerBill, has interesting stuff to say, and he's very humble.
That doesn't mean you should actually use any of these languages, but still can be interesting to look at.
Generally speaking, looking at stuff that you're not constantly being told to look at is not a bad move.
-
For a young EE studying nerd? Quite a lot!You guys are throwing me back to when I was (happily) subscribed to "Computer Language" magazine!
Thank you!
was/is it interesting?
Read the number with the interviews to Knuth and Wirth.
But TBH, my original subscription was for Micro Cornucopia, a treasure trove of hardware and software information, which unfortunately folded shortly after I paid my second year.
They offered to transfer the subscription to a small number of magazines - remember those?
I selected CL as I was buying it already from time to time.
-
I find it hilarious they absolutely had to remove goto, but then creep in a feature of adding a new kind of goto which can arbitrarily jump around inside switch-case: something no one ever asked, switch-cases being quite confusing already as they are.
-
I find it hilarious they absolutely had to remove goto, but then creep in a feature of adding a new kind of goto which can arbitrarily jump around inside switch-case: something no one ever asked, switch-cases being quite confusing already as they are.
As I've seen, they removed the need for 'break' inside switch's, making them behave as the Pascal/Ada 'case' constructs by default. But then added the 'nextcase' statement to allow falling through.
'nextcase' doesn't allow to jump around freely but only to the next 'case', as I've got it at least.
In order words, they inverted the default behavior in switch-case, which is not a completely stupid idea.
You're wrong in saying "no one asked for that". Fallthrough is the only way of combining multiple cases. People use that all the time. And so, once you decide to remove the fallthrough behavior as default, this 'nextcase' statement is the logical step. You need it, unless you give up on having multiple cases leading to the execution of the same code.
The problem is that it's a half-baked solution: outside of cryptic constructs like the Duff's device, using fallthrough in switch-case in C was mostly meant to emulate the possibility of having cases for multiple values instead of just one. That was much better addressed even in Pascal (if I remember it right) using ranges.
But obviously a 'nextcase' statement is much easier to implement.
-
'nextcase' doesn't allow to jump around freely but only to the next 'case', as I've got it at least.
No, look closer - clearly that was their original idea, but they feature creeped their "fallthrough" to take an argument, allowing you to jump to any other cases, in any order. I'm ridiculing this feature.
I agree with the inversion from implicit fallthrough to making it explicit. Not only it saves from typing boilerplate (break is the usual case), it reduces human error. -
Here we go again. Is there somebody who really believes C is going to be replaced?
I don't for various reasons. C has been here for a long time and it will stay here for even a longer time.
I agree though, it's fun to watch the attempts and it can be interesting to analyze them.
-
I'm ridiculing this feature.
But why?
It's so beautiful!
Now you don't need if, while, do and for.
Every structured flow control can be achieved with a suitable switch statement!
/s, in case it's needed.
I don't find the nextcase feature (even the basic one) especially compelling.
In a way, it's already there in C as compilers warn when falling through cases.
Break is still there, (and the possibility of leaving named scopes is indeed nice) this just removes one of its uses. -
Here we go again. Is there somebody who really believes C is going to be replaced?
I don't for various reasons. C has been here for a long time and it will stay here for even a longer time.
there are only to kinds of people: those who are spending time wondering *** if *** { C/89 , C/99 } could be replaced ... (and with what?) and those who have actually already replaced (improved? just modified? just made it weirder? ... mumble, dunno what's the correct verb here) C and re-written a small uKernel as well as a b+tree filesystem, and are very happy that it took just 1/4 of the effort was taken with C/89
-
Here we go again. Is there somebody who really believes C is going to be replaced?
I don't for various reasons. C has been here for a long time and it will stay here for even a longer time.
there are only to kinds of people: those who are spending time wondering *** if *** { C/89 , C/99 } could be replaced ... (and with what?) and those who have actually already replaced (improved? just modified? just made it weirder? ... mumble, dunno what's the correct verb here) C and re-written a small uKernel as well as a b+tree filesystem, and are very happy that it took just 1/4 of the effort was taken with C/89
I always use gcc with option -std=gnu11. No problems here, programming has never been easier using GNU/Linux, make and GCC.
Not saying here that everybody should do like me. Just telling what works best for me.
-
No problems here, programming has never been easier using GNU/Linux, make and GCC.
Not saying here that everybody should do like me. Just telling what works best for me.
frankly I feel really frustrated by answer like this. -
No problems here, programming has never been easier using GNU/Linux, make and GCC.
Not saying here that everybody should do like me. Just telling what works best for me.
frankly I feel really frustrated by answer like this.
Please don't, it's not worth it. Use what works best for you.
-
IMHO the only thing that C ever needed is a .length attribute for arrays.
I'm sick and tired of bugs introduced by using sizeof() on an array when you should have used sizeof(a)/sizeof(a[0]). Looking at you, handsome guy in the mirror pointing at me.