On Fri, 21 Jun 2024 21:14:19 +0200 Markus Wichmann <nullp...@gmx.net> wrote:
> Am Thu, Jun 20, 2024 at 11:53:45PM +0200 schrieb Страхиња Радић: > > Given that, why complicate code by introducing a separate, superfluous, > > type? > > Let me offer a counterpoint: Expressiveness. If I make a function return > a bool, then everyone from the world's worst junior dev to Ken Thompson > himself will be able to see at the very first glance that the function > is returning a boolean value. If I make a function return an int, that > is not so clear. Expressiveness is great, but _Bool is more than just an expression of intent. If _Bool was nothing more than a typedef of int, it would be great. However, in the real world, I also find that boolean isn't expressive enough and enum is needed. This is because people do silly things like returning true or false, without it being obvious that the function should even return anything at all, do indicate for example if the function was successful, or the action was completed or need to be made again, or if the action modified the stated (could be true if the state was not modified or true if the state was not modified). > > That said, if a function returns bool and is longer than one or two > statements, it is probably already doing something wrong. I have seen > bool used as error code, and it is such a missed opportunity to return > an enum of error codes to say what actually went wrong. > > > Every new iteration of C after C99 introduced more unnecessary cruft. > > C99 is the best version, although it has its rough edges, one of which > > is the _Bool type. > > > > All versions of C after C89 added more stuff that wasn't there before. > That is mostly the point. You cannot remove things without introducing > an incompatibility. So the only thing I can remember that was ever > removed was gets(), which was a bad idea from the start, and finally > removed in C11. > > I don't know, to me statements like "C99 is the best version" are always > funny. Not so long ago, this very list opined that C89 is the only true > C standard and everything that came after is "not C", as I recall. Which > is literally wrong, of course (C is whatever WG14 says it is, whether > you like it or not). > > Isn't it all about familiarity in the end? Or can you articulate what > parts of C11 and C23 you find objectionable? C99 added a lot of good features. And just a couple of questionable features: //, <stdbool.h>, and intermingled declarations and code. So this was a very good improvement C95 added digraphs, <iso646.h>, and the not-too-well-designed <wchar.h> and <wctype.h>, which aren't that commonly used; so while making some improvements, this wasn't the best of improvements. I think C11 really brought some nice improvements, but you don't need them too often, so C99 is often enough: _Aliasas, _Alignof, aligned_alloc, _Thread_local, _Atomic, anonymous nested structs and unions, _Generic. It also adds a lot of things that I could take or leave. There's nothing to objectionable in C11, even if things code be better designed. C17 only addressed defects in C11, so this version is completely non-objectionable. C23 really does add some nice things that have been missing, but most often them don't actually have to be a part of C. One thing I really do like about C23 is __VA_OPT__. I don't see with we need nullptr, nullptr_t and _BigInt looks like a big design blunder. I find changing the meaning of the auto keyword, and to a lesser extent making true, false, alignas, alignof, bool, static_assert, and thread_local keywords, objectionable. While not technically objectionable, I personally find the [[ ]]-syntax for attributes unstylish. But worst of all might be making `int foo()` equivalent to `int foo(void)`. > > Ciao, > Markus >
