Re: [dev] [dwm][st] why use ints over bools?

From: Mattias Andrée <maandree_AT_kth.se>
Date: Fri, 21 Jun 2024 22:12:15 +0200

On Fri, 21 Jun 2024 21:14:19 +0200
Markus Wichmann <nullplan_AT_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
>
Received on Fri Jun 21 2024 - 22:12:15 CEST