7 ms·

Good suggestions, but also meh, e.g.: forward declaration requirement enables a single-pass compiler to emit code on-the-fly. I have a much better list for thi

Good suggestions, but also meh, e.g.: forward declaration requirement enables a single-pass compiler to emit code on-the-fly. I have a much better list for things to add to C: Nothing. C isn't perfect, or nearly as good as it could be, but simply adding things onto C gets you C++. Adjusting what sircmpwn says: in C you don't solve problems by adding features, but by writing more code in C. I liked an answer on stack overflow on a question on "how to write a generic function wrapper in Go", or something similar. Many suggestions included reflection, but the author wanted something simpler with varargs without reflection. A comment simply said: "wrong language". I'd rather adopt this position for some languages, instead of add more and more to C3X. I do away with things in C23, and don't want even more things added in to C. Making a strech of OP's arguments: "look at all this cool things that C could do, and that D does!". Well, go on and use D, nothing wrong with that. (BTW, I do write test targets for every file in my C projects, but I'm not so much into jogging). Those things aren't that obvious, and I'd rather not have them added to C. Wrong language.

EuAndreh 2y ago
I have my own list of things that could "easily" be added to C, but I'd rather them not to be.
- WalterBright 2y ago
  You get them anyway in the form of extensions.
  - EuAndreh 2y ago
    Thanks, but no thanks.
WalterBright 2y ago
> forward declaration requirement enables a single-pass compiler to emit code on-the-fly. True, I know all about that. My Zortech C and C++ compiler was one pass (after the multiple preprocessing passes). The ground up ImportC C compiler completed a couple years ago has a separate parse pass. So I well know the tradeoffs. The parser being stand-alone means it is much simpler to understand and unittest. I found no advantage to a single pass compiler. It isn't any faster. > simply adding things onto C gets you C++ C++ doesn't allow forward declarations either. Successfully doing a parse-only on C code doesn't quite work. It turns out the grammar relies on a symbol table. Fortunately, only a symbol table of the typedefs. Once adding that in, ImportC worked. (I really tried to make it work without the typedef symbol table!) C++ added a bunch more syntax that relies on the symbol table. I would not even try fixing it to work as parse-only. > in C you don't solve problems by adding features, but by writing more code in C The trouble with such sayings is like following a google map that says cross this bridge, but wasn't updated with news that the bridge is out. > Those things aren't that obvious, They are once you use another language that doesn't have those restrictions. > and I'd rather not have them added to C. C adds new things all the time to the Standard, like normalized Unicode identifiers, which are a complete waste of time. Every C compiler also adds a boatload of extensions, some good, some wacky, many ineptly documented, all incompatible with every other C compiler extensions.
- EuAndreh 2y ago
  > The parser being stand-alone means it is much simpler to understand and unittest. Stand-aloneness and single-passness are orthogonal. > I found no advantage to a single pass compiler. It isn't any faster. A gigantic advantage: a single-pass-compilable language is simpler. By definition. Implementations may or may not be simpler or faster. > C++ doesn't allow forward declarations either. Well, that's not what I meant. C++ is "C with just this thing" done way too many times. > The trouble with such sayings is like following a google map that says cross this bridge, but wasn't updated with news that the bridge is out. TBH, I didn't really get this. Is this about sticking to C as is, but it is outdated as is? C would be outdated if it didn't have, say, long long for 64-bit numbers. Having "true" be a keyword instead of a macro doesn't change how outdated it is or isn't, just like compile-time evaluation also doesn't. > They are once you use another language that doesn't have those restrictions. I have used many, and I still don't find them obvious. > C adds new things all the time to the Standard, like normalized Unicode identifiers, which are a complete waste of time. I agree that many/most are a waste of time, and shouldn't be added to C. The fact of C adding things to the standard all the time shouldn't justify adding even more things, but make one question if those are needed at all, and how to accomplish the goal without it. > Every C compiler also adds a boatload of extensions, some good, some wacky, many ineptly documented, all incompatible with every other C compiler extensions. I know about that, and my position is the same: just don't. I don't use them also.
  - Dylan16807 2y ago
    > A gigantic advantage: a single-pass-compilable language is simpler. By definition. That's only "by definition" if you take a language that needs multiple passes, then remove the features that need multiple passes, and don't replace them with anything else to compensate. The "by definition simpler" version of C would not only disallow forward references, it would have no forward declarations either. As-is, forward declarations add some complexity of their own. (Also, if you can figure out a way to emit jump instructions in a single pass, you can probably figure out a way to call unknown functions in a single pass.)
    - 2y ago

EuAndreh 2y ago

I have my own list of things that could "easily" be added to C, but I'd rather them not to be.

WalterBright 2y ago
You get them anyway in the form of extensions.
- EuAndreh 2y ago
  Thanks, but no thanks.

WalterBright 2y ago

> forward declaration requirement enables a single-pass compiler to emit code on-the-fly. True, I know all about that. My Zortech C and C++ compiler was one pass (after the multiple preprocessing passes). The ground up ImportC C compiler completed a couple years ago has a separate parse pass. So I well know the tradeoffs. The parser being stand-alone means it is much simpler to understand and unittest. I found no advantage to a single pass compiler. It isn't any faster. > simply adding things onto C gets you C++ C++ doesn't allow forward declarations either. Successfully doing a parse-only on C code doesn't quite work. It turns out the grammar relies on a symbol table. Fortunately, only a symbol table of the typedefs. Once adding that in, ImportC worked. (I really tried to make it work without the typedef symbol table!) C++ added a bunch more syntax that relies on the symbol table. I would not even try fixing it to work as parse-only. > in C you don't solve problems by adding features, but by writing more code in C The trouble with such sayings is like following a google map that says cross this bridge, but wasn't updated with news that the bridge is out. > Those things aren't that obvious, They are once you use another language that doesn't have those restrictions. > and I'd rather not have them added to C. C adds new things all the time to the Standard, like normalized Unicode identifiers, which are a complete waste of time. Every C compiler also adds a boatload of extensions, some good, some wacky, many ineptly documented, all incompatible with every other C compiler extensions.

EuAndreh 2y ago
> The parser being stand-alone means it is much simpler to understand and unittest. Stand-aloneness and single-passness are orthogonal. > I found no advantage to a single pass compiler. It isn't any faster. A gigantic advantage: a single-pass-compilable language is simpler. By definition. Implementations may or may not be simpler or faster. > C++ doesn't allow forward declarations either. Well, that's not what I meant. C++ is "C with just this thing" done way too many times. > The trouble with such sayings is like following a google map that says cross this bridge, but wasn't updated with news that the bridge is out. TBH, I didn't really get this. Is this about sticking to C as is, but it is outdated as is? C would be outdated if it didn't have, say, long long for 64-bit numbers. Having "true" be a keyword instead of a macro doesn't change how outdated it is or isn't, just like compile-time evaluation also doesn't. > They are once you use another language that doesn't have those restrictions. I have used many, and I still don't find them obvious. > C adds new things all the time to the Standard, like normalized Unicode identifiers, which are a complete waste of time. I agree that many/most are a waste of time, and shouldn't be added to C. The fact of C adding things to the standard all the time shouldn't justify adding even more things, but make one question if those are needed at all, and how to accomplish the goal without it. > Every C compiler also adds a boatload of extensions, some good, some wacky, many ineptly documented, all incompatible with every other C compiler extensions. I know about that, and my position is the same: just don't. I don't use them also.
- Dylan16807 2y ago
  > A gigantic advantage: a single-pass-compilable language is simpler. By definition. That's only "by definition" if you take a language that needs multiple passes, then remove the features that need multiple passes, and don't replace them with anything else to compensate. The "by definition simpler" version of C would not only disallow forward references, it would have no forward declarations either. As-is, forward declarations add some complexity of their own. (Also, if you can figure out a way to emit jump instructions in a single pass, you can probably figure out a way to call unknown functions in a single pass.)
  - 2y ago