I don't know. A "Comparison between constans will always be true/false. This might not be what you want."-varning might be better.

/ Peter Bortas

Previous text:

2003-02-12 13:48: Subject: Search bug ?

---

Well, why would 1=="foo"?

/ Per Hedbor ()

s/sort/sort or search/

search should be of type

function(array(mixed),mixed:int(-1,...))

(hmm, or does it accept a strng as first argument too?)

/ Niels Möller ()

Previous text:

2003-02-12 14:16: Subject: Search bug ?

---

To me it seems like the type system is far too strict here. `= should be of type function(mixed,mixed:int(0,1)). Calling it with arguments of different tpes should return false, but it can never be a type error.

And the same goes for functions like sort that wants to compare elements. It should not require that the types are the same, as any two objects of any types can be compared.

/ Niels Möller ()

Getting a type error when doing a[0]=="b" has helped on many occasions though.

/ Martin Nilsson (Åskblod)

Previous text:

2003-02-12 14:16: Subject: Search bug ?

---

To me it seems like the type system is far too strict here. `= should be of type function(mixed,mixed:int(0,1)). Calling it with arguments of different tpes should return false, but it can never be a type error.

And the same goes for functions like sort that wants to compare elements. It should not require that the types are the same, as any two objects of any types can be compared.

/ Niels Möller ()

"must" is a strong word here. Nilssons example fatal is usefull. If the only reason for allowing it is ortogonality I'd rather have it stay as is.

/ Peter Bortas

Previous text:

2003-02-12 16:40: Subject: Search bug ?

---

Warnings like "comparison is always false" can be useful, but it must not be treated as an error.

/ Niels Möller ()

I used "must", because I think it is insane to get a compilation error just because I search an array for some object that doesn't occur there.

Say I have a lyskom module, that let me set KOMNAME or KOMNUMBER in the environment.

string|int me;

void create() { me = getenv("KOMNAME") || (int) getenv("KOMNUMBER"); }

A program could use it like

if (kom.me == 5) werror("Welcome ceder\n");

or

if (search( ({ 5, 17, 4711 }), kom.me) >= 0) ...;

But running that program would result in a compilation error if KOMNAME=nisse?

/ Niels Möller ()

Previous text:

2003-02-12 17:10: Subject: Search bug ?

---

"must" is a strong word here. Nilssons example fatal is usefull. If the only reason for allowing it is ortogonality I'd rather have it stay as is.

/ Peter Bortas

No. The code that gets the compilation error is obviously not running. Pike doesn't run a program until after it's been successfully compiled, right?

And if you don't like the environment dependence, replace that with a module that's generated at install time. The code handles a compile constant, say "x", that can be a string or an int. It wants to compare it to some constant values:

// Created at install time. Contains // either constant x = 7; or constant x = "foo"; import config; ... if (x == 10) ...

It's insane to have to rewrite that as

if (numberp(x) && (int) x == 7) ...

just to get it through the compiler. Next thing, we're defining the type of numberp so that numberp("foo") also generates a compile time error.

I mean, if 7 == "foo" is not a run time error (and it isn't, it just evaluates to 0, and that's by *design*, not because of a bug in the run time type checking), then it's utterly broken to generate a compile time error for the same expression. I'm getting annoyed, so I'll shut up now.

/ Niels Möller ()

Previous text:

2003-02-12 18:30: Subject: Search bug ?

---

Those are run-time checks.

/ Peter Bortas

I agree, it shouldn't be an error.

/ Martin Stjernholm, Roxen IS

Previous text:

2003-02-12 16:40: Subject: Search bug ?

---

Warnings like "comparison is always false" can be useful, but it must not be treated as an error.

/ Niels Möller ()

Agree. For control flow, I think it makes more sense to warn for if and switch than for the loop constructs.

/ Niels Möller ()

Previous text:

2003-02-12 21:17: Subject: Search bug ?

---

I think it's very obscure that the type system creates errors, that with the same input wouldn't generate an error runtime.

I'd like to instead see warnings,

1. when equal and `== gives constant results:

1==1, 1==2 equal( ({1}), ({2}) )

2. when the code flows on constant results:

if (1) ... if (0) ... switch (0) ...

In these cases it's very probable that you didn't want to do that. But to make sure you can do that anyway without warning, how about a pragma to turn off that specific warning?

Some constant flow control is common and is probable futile to warn for, so we should possibly not do that here:

for (;;) ... while (1) ... do ... while (0);

/ Mirar