I wish for a better BOOLEAN operation within the IF statement.

[flowCRANE]

There is no way for the compiler to decide, with context or otherwise, what it should do.  It could interpret that statement as true and true = true which would be true or it could just as well interpret it as a bitwise operation compared to the numeral 1, 111 and 101 = 1 which would be false.

And again operands, operators, instead of result of the expression, calculated in the standard way…

I will not explain the same thing for the third time, I'm sorry.

[440bx]

I will not explain the same thing for the third time, I'm sorry.

Don't be.  I'm very pleased you won't.

[flowCRANE]

And everything is clear. I know my own, you know yours and stay with it.

[munair]

There is no way for the compiler to decide, with context or otherwise, what it should do.  It could interpret that statement as true and true = true which would be true or it could just as well interpret it as a bitwise operation compared to the numeral 1, 111 and 101 = 1 which would be false.

And again operands, operators, instead of result of the expression, calculated in the standard way…

I will not explain the same thing for the third time, I'm sorry.

The result of an expression is not known until it has been evaluated, which is why a compiler needs to know unambiguously how to evaluate an expression. There are compilers that allow for variable definitions whereby the type is determined by the result of the evaluation:

Code: Text  [Select][+][-]

1. var c = a and b

This is only possible if the ASSIGN operator is the lowest in the order of operations, which it always is.

[Kays]

Why can't we do this like in C ?
If SomeInteger then.....

Because this is missing:

Code: Pascal  [Select][+][-]

1. {$mode objFPC}
2. operator := (const i: nativeInt) b: boolean;
3. begin
4.         b := i <> 0;
5. end;

Unfortunately I get a

Code: [Select]

destroyPascal.pas(5,44) Error: Impossible operator overloaderror with FPC 3.0.4+dfsg-11. Why is it impossible?

[jamie]

In short the compiler already knows how to do it..

if Boolean(SomeInteger) then.....

So because  there is no >= <= = etc after SOMEINTEGER, the compiler should understand this
as an Boolean operation..

Also this..

if (SomeInteger <> 0) and (SomeOtherIneger <> 0) then...

Translated to this
 If (SomeInteger) and (SomeOtherInteger) Then...

As it stands, doing it the PASCAL way still generates Booleans...

if (SomeInteger <> 0) Then // Will result in a True  /False operation.

So I really don't see the issue here with allowing this..

As stated also, this can also work with pointers..

 If SomePointer then.... //Which means its not NIL...

 the fact there isn't any operations after the identifier should signal a Boolean operation.

I only wanted to have this option for the "IF,UNTIL and WHILE " operation.

Assignment operations should not be allowed.
For example
 SomeBoolean := SomeInteger; // This should not ever be allowed
however
 SomeBoolean := SomeInteger <> 0; // This  is ok because the compiler results in a bool anyways.



Oh well, It was just a thought...

[Leledumbo]

Oh well, It was just a thought...

We get insane requests (those that try to break the language integrity and safety features without any significant practical benefit as a trade off) like this from time to time, and fortunately the devs are sane enough not to allow it, even if patches are given. You can search the forum for posts mentioning features from other languages, simply because that person are used to that particular language's decision, which doesn't make sense to me. Don't think in one language perspective when coding in another, every language has its own decision with regard to certain features.

Code: Pascal  [Select][+][-]

1. if X <> 0 then
2.  

may type longer (by only a few characters) than"

Code: Pascal  [Select][+][-]

1. if X then
2.  

but the semantic needs no guessing. I think 440bx has explained the best a case where there are multiple interpretation of an expression. Ambiguity can be solved by stating which interpretation the compiler will take, but is not easily understood by reader without reading the relevant documentation (if at all documented). Why make things difficult when you can make it easy through simple unambiguity? Again, there's practically 0 gain (I don't count a few characters less to type as a gain, it's laziness) even if this feature is allowed and implemented.

[Thaddy]

Because this is missing:

Code: Pascal  [Select][+][-]

1. {$mode objFPC}
2. operator := (const i: nativeInt) b: boolean;
3. begin
4.         b := i <> 0;
5. end;

Unfortunately I get a

Code: [Select]

destroyPascal.pas(5,44) Error: Impossible operator overloaderror with FPC 3.0.4+dfsg-11. Why is it impossible?

Because the explicit variant of the assignment operator := is already active in the compiler. That's why the Boolean cast works out of the box:Boolean(100); And that's why it is an impossible operator overload.

[marcov]

In short the compiler already knows how to do it..

if Boolean(SomeInteger) then.....

Result is undefined for values other than 0 and 1.

[Thaddy]

@Marco
AFAIK , no, the compiler resolves it with the zero comparison. But if that would be the case (undefined)  you can use one of the bool types (not Boolean) which makes it defined in all cases and independent of implementation detail.
if longbool(SomeInteger) then

Caveat: if you need 0 or 1 (for ord(),pred(),Succ() etc) you need to do this: if Boolean(longbool(SomeInteger))...

[Kays]

[…]

Code: Pascal  [Select][+][-]

1. […] operator := (const i: nativeInt) b: boolean; […]

[…]

Because the explicit variant of the assignment operator := is already active in the compiler. That's why the Boolean cast works out of the box:Boolean(100); And that's why it is an impossible operator overload.

Huh. To my knowledge there are the two assignment-related operator overloads imaginable:

Code: Pascal  [Select][+][-]

1. operator := (const i: nativeInt) b: boolean;

and

Code: Pascal  [Select][+][-]

1. operator explicit (const i: nativeInt) b: boolean;

the former of which being used for implicit typecasts, while the latter applies to explicit typecasts you mentioned. If I can't do something like

Code: Pascal  [Select][+][-]

1. var
2.         i: nativeInt;
3. begin
4.         i := true;
5. end;

I conclude the former is not defined. This doesn't touch the issue that the explicit operator is already defined. Trying to overload it yields the same “impossible overload”-error. It is really confusing to me, that one of the operators you claim being “active” isn't actually usable, but still thwarts the definition of.

[Thaddy]

operator implicit is not available for stand-alone operators as in mode objfpc, afaik. Just := and that one is here also a compiler intrinsic. I haven't tested yet if maybe longbool is available.
[edit] nope..

[ASBzone]

if (SomeInteger <> 0) and (SomeOtherIneger <> 0) then...

Translated to this
 If (SomeInteger) and (SomeOtherInteger) Then...

As it stands, doing it the PASCAL way still generates Booleans...

But (SomeInteger <> 0) is an expression, whereas (SomeInteger) is not.

Just because you know what you mean or desire when you see the latter, does not vault it into the category of expression.

[marcov]

@Marco
AFAIK , no, the compiler resolves it with the zero comparison.

Undefined can happen to work, it is just not guaranteed. Yes, use longbool.

p.s. That said, looking back, since boolean (1-byte) and integer (4-byte) are not the same type, it is not a pure cast, so maybe the conversion fixes it. But I also doubt how defined this is.

[guest58172]

if (SomeInteger <> 0) and (SomeOtherIneger <> 0) then...

Translated to this
 If (SomeInteger) and (SomeOtherInteger) Then...

As it stands, doing it the PASCAL way still generates Booleans...

But (SomeInteger <> 0) is an expression, whereas (SomeInteger) is not.

Just because you know what you mean or desire when you see the latter, does not vault it into the category of expression.

Of course it is an expression. It's a primary expression. of simple-expression following the official names.
It's like if you say that a function call without parens is not an expression.
It is, then the meaning is determined during semantic passes.