Apple

I keep seeing "BOOL type" thrown around like it is a first class citizen.

Is it not a typedef ... a signed char maybe? See objc.h ...

Are we essentially asking for a warning every time an truthy clause isn't using a "signed char"? Can the current implementation of clang distinguish an explicit BOOL clause from its bitwise identical cousins?

---

objc.h

#define OBJC_BOOL_DEFINED

/// Type to represent a boolean value.

#if !defined(OBJC_HIDE_64) && TARGET_OS_IPHONE && __LP64__

typedef bool BOOL;

#else

typedef signed char BOOL;

// BOOL is explicitly signed so @encode(BOOL) == "c" rather than "C"

// even if -funsigned-char is used.

#endif

#if __has_feature(objc_bool)

#define YES __objc_yes

#define NO __objc_no

#else

#define YES ((BOOL)1)

#define NO ((BOOL)0)

#endif

On Thu, Oct 17, 2013 at 9:33 PM, Jens Alfke <email@hidden> wrote:

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.

Right. It’s a dangerous exposed sharp edge in the language syntax, where leaving out a single “=“ completely changes the meaning of an _expression_. It’s caused so many bugs over the decades that it’s generally recognized as a Bad Idea that probably shouldn’t have been allowed to begin with, but at least now there’s a warning you can enable for it.

—Jens

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)

This email sent to email@hidden