Cyrus' Blather

The conditional part of the for(...) is constant, and therefore, an infinite loop will occur.

(Duh;)

Austin: the "What could be wrong with that??" was rhetorical.

I was more angry that C++ allows non boolean conditionals.

Bane of my life I tell you.

I know. (Hence the ;) by the Duh).

While annoying at times, it's one of those power features certain people like myself miss when working with C#.

Orion Adrian

Orion: I'm not sure I see anything powerful about that feature at all.

Austin: Sorry :-)

Missed that.

Cyrus,

i disagree. its nice to have non-boolean conditions. in c#, i hate it to be forces to write...

object o = null;

if( o == null)

instead of if( o)

yes, the c# compiler makes sure that i make sure i know what i do. but quite often, i'd rather decide myself. each time i have to write '== null', for example.

WM_DISAGREE
thomas woelfer

Thomas: Again, I'm seeing no extra power in that feature :-)

What does if (object) mean?

I see that for you it means "if it exists". However, existence to me is such a vague quantity that I feel it should not be inferred by the compiler.

For example, what does:

if (4) { }

mean?

why does it mean anything else other than

if (0) { }???

Both are numbers, both exist. So why should they behave differently. Ah... because if has historical roots. It used to mean "if the expression evaluates to something with a non-bit value of all 0's then execute the following statement". However, this concept is meaningless in C#. Numbers/Objects/instances/nulls are not thought of as just a representation of a bit pattern.

i.e. in C# 0, null, false are all completely different values that you can't ever assume is equivalent. We could overload "if" to handle every type of input. Like:

if (int)
if (bool)
if (object)

etc.

However, what if we took it one step further and defined:

if (string)

Where we would execute the statement if the string was non-null _and_ non-empty? Would you be ok with that? If not, why not? Presumably because you'd feel that "if" should only be testing against null. But, again, I feel that this is a historical throw back.

"if" was therefor mapped to it's logical equivalent. In predicate logic "if" is only validly applied to an expression that will return a boolean. So, similarly in C# we have that restriction. Because of this we require the type to be boolean as well.

For those worried about perf.

The jitter would take
if (foo != 0)
and
if (foo)
and will compile down to the same assembly. So there is nothing gained by by the brevity, except the confusion of asking yourself. What does it mean to "test" an element from your non-boolean domain.

Another one to think about is structs. How are structs tested in an "if" statement.

Then, once you've decided on what should happen with structs, then decide what should happen with Nullable<T>. It's a struct. However, it also represents a null value. Does that suddenly mean we have to redefine what "if" means in that case?

Well us "old time" C programers have just done if (foo) a lot and don't like change :).

But, even saying that, I think that...

if (foo) /* if foo */

...reads a lot better than...

if (foo != null) /* if foo not equal nothing */

....as for the string argument, python, perl, etc. all opt. for if (foo) to do the test and have something else to just test for null ... so that's what I'd expect.
In the words of some bloke, "perfect is the enemy of good".

I'm going to have to go with thomas and just say i disagree :-)

"if foo" doesn't read well for me at all. I need to at least say: "if foo exists" or "if i have an instance of foo" or "if foo isn't null"

I think "if foo" reads well for you simply because you've been saying it a long time. It doesn't read well for me because it's not something I can ever say in real life.

However, if i say "if foo exists" or "if foo isn't 0" then that is very readable to me.

To me, it's like saying "while the number of almonds, eat an almond" rather than "while the number of almonds isn't zero, eat an almond" (i'm eating almonds right now). Conditionals like while/if/etc. just can't be spoken with any meaning unless they are applied to something domain that maps onto a logical structure (like boolean, or trinary logic). So we have to state them as something like "if foo exists then". or "if bar isn't 0"

I am not content for "if number" to automatically mean "if number isn't 0", although I _might_ be ok with the statement "if foo" being shorthand for "if foo exists"

existence is a concept that might map into this area. However non-zero-ness simply doesn't work for me. "0" is not "does not exists" any more than "non-zero" is "exists"

---

as to the last part, i think you've explained it fully. You expect it to behave like other programming languages. However, which ones? What if dylan treats it differently? What about ruby? What about VB? you can't get a consensus on this because there will always be a language out there that does it differently.

An even better reason why if(foo) is bad:

Foo foo = new Foo();
FooBar foobar = new FooBar();
object obj = foobar;
if(foo) {
Console.WriteLine("Foo");
}
if(foobar) {
Console.WriteLine("FooBar");
}
if(obj) {
Console.WriteLine("Object");
}

What do you think it will print?

What if I told you that, in the far away file where FooBar is defined, it says, among dozens of other things:

class FooBar {
...
public static bool operator true(FooBar foobar) {
return false; // or other condition not established by the default constructor
}
}

Weren't expecting that? I wouldn't be either. But see section 7.14 of the C# defintion. Oops.

Doug: Don't even get me started on implicit conversions!! :-)

Bleagh......

"What could be wrong with that??

Aaaaaaaaaaaaaaaaaargh. Curse you C++!!!!!!!!!!!!!!!! Can't that at least be a warning?"

What's it meant to warn you about?

For all the compiler knows the code could be:
for(int i(0); parameters.GetCount(); ++i)
{
cout << "The " << i << "th parameter is " << parameters.Top() << endl;
parameters.PopTop();
}

Dr Pizza: It's meant to warn me that the conditional expression is not actually a boolean conditional.

As all the posts in here have shown, i don't believe in implicit conversions. Especially between something like numbers and booleans. 0 does not mean false in any system for me. Just as non-zero doesn't mean true either.

I'm well aware of why that code compiles and runs. But what I would like is to tell the compiler "warn me if the expression in the condition does not evaluate to a boolean expression.

Does that clarify it?

if foo is a bad example. how about
if (mouseexists)

Dung: What about it?

That seems perfectly reasonable if mouseExists was a boolean type...

No. Stick shifts rule. :-)

http://weblogs.asp.net/mikhailarkhipov/archive/2004/07/22/191682.aspx

why hate it? say the function returns a value based on a shared memory that changes everytime? say a register, etc. isn't it a good feature?

Piping Pepito: How would that change anything?