Re: Any way to get a warning if a non-boolean type is used in an if expression?
Re: Any way to get a warning if a non-boolean type is used in an if expression?
- Subject: Re: Any way to get a warning if a non-boolean type is used in an if expression?
- From: Thomas Wetmore <email@hidden>
- Date: Fri, 18 Oct 2013 00:33:04 -0400
Jens,
I'm not appealing to the way K&R designed C in 1970. I'm stating semantics as they are today. C has evolved, but in terms of its expressions and statements, it is the same language it was 45 years ago. And though Objective-C is a wonderful veneer on top of C, it is still a veneer, and inherits those same semantics. If we choose to use Objective-C, we should understand it.
Having an if-statement that uses 0/nil for false and anything else for true, is orthogonal to issues such as type checking and function prototypes. This definition is simple, elegant and powerful, and helped unleash much of the terse expressiveness inherent in the C language. 45 years ago this expressiveness was touted as a major advantage of C. Today this expressiveness is often maligned as a cause of poor programming practices. Rat holes and pointless arguments lie in that direction.
My point is only that one should know their language and use their language effectively. When one fully understands that if(a) and if(a!=0) if(a!=nil) all mean exactly the same thing (and compiled into identical assembly), one can make a reasoned decision about which form to prefer in their code. Because of my age and experiences I use the terser form. Others here clearly prefer the less terse. I have no issue with the "!= 0" crowd writing code their way. My issue comes when those in that crowd display so little knowledge of their language that they believe a warning is required to insult the intelligence of members of the terse crowd.
Tom
On Oct 17, 2013, at 10: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)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden