On Fri, Jun 21, 2024 at 10:12:15PM +0200, Mattias Andrée wrote: > 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,
Doesn't the function having a return type make it obvious that it returns something? > 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). If I have a function like "bool is_cromulent(foo)", I'd expect it to return true when foo IS cromulent (or 1 if the return type is int). Are you saying it should return cromulence_t with values either IS_CROMULENT or IS_NOT_CROMULENT? > > [...] Not so long ago, this very list opined that C89 is the only true > > C standard [...] If there was a new poll, I demand a recount! -- Storkman
