Apple

On Oct 17, 2013, at 5:28 PM, Thomas Wetmore <email@hidden> wrote:

In C, and therefore in Objective C, there is no such thing as a "boolean _expression_". There are only expressions.

Languages evolve. Appeals to “that’s not the way K&R designed it in 1970” don’t seem that convincing to me. Original C didn’t have function prototypes either, and it made you declare all the variables at the top of a block. C was really, really vague about data types, partly because it grew out of BCPL whose only data type was “int”.

(I used C back in the ‘80s and gave up on it, until ANSI C, in favor of Pascal because the combination of machine-level semantics with zero parameter type checking was really dangerous and led to large numbers of crashing bugs. _javascript_ doesn’t check parameter types or count either, but at least it’s high level enough that it doesn’t explode when you pass a short instead of a long.)

Thinking that the _expression_ must (or even should) have the form of some kind of logical _expression_ is simply false and against the character of both C and Objective-C.

Again, this is just That’s Not How We Used To Do It.

I’ve noticed that most new strongly-typed languages I see require that conditionals be explicitly of boolean type — Go, Rust and Scala come to mind. I admit I still sometimes forget to add “!= nil” when coding in Go, but I understand the reasoning behind the restriction.

Some may think that explicitly checking a pointer for a nil-value is "good programming" practice, and if you do, go ahead and write it that way. But when you understand the semantics of the language, there is no need for such a form, and to some it looks odd.

By this argument there’s no need for type-checking errors/warnings, either, right? Back to BCPL!

Non-sarcastically: The reason for making conditionals be boolean type is precisely because its enforcement by the compiler catches unintentional errors, such as the one that inspired this thread.

Going a little further I do not like the fact that clang issues a warning for using an assignment type _expression_ in an if _expression_; many good good C idioms use that technique to good effect. But since adding an extra pair of parentheses will silence the warning, I go along with it. I admit that that warning has found a couple bugs for me.