Boolean type

[Thaddy]

Is it documented anywhere? When can we expect conversion instead of cast?

It is documented on the fp-devel list at least.
The argument focussed on conversion in the sense that Pascal programmers would expect a value vs my dissenting opinion that the bitwise representation should be respected. I was in a minority of one (maybe two). And it was not my "usual" erratics, but firmly founded in theory and with examples.
It is to my knowledge also in the official documentation, but have to look that up: there is a reasoning somewhere that explains that fpc converts instead of leaving it alone.
[edit]
Found it, implicit and partially.
https://www.freepascal.org/docs-html/ref/refse85.html.

(and I am still of the opnion that a bit pattern representing either an integer or float of the same size should NOT be converted. 440bx code example shows the same)

Anyway, either over-casting or pointer magic can save the day.

[440bx]

Boolean vs Byte (or any other storage) is not a conflict.

it shouldn't be a conflict but, FPC equates boolean to bytebool, that's a problem and a conflict because a boolean isn't a byte.  A boolean can only host 2 values, a byte can host 256 values, quite a difference.

What is downright atrocious is that FPC accepts a typecast such as boolean(73).  It's atrocious because 73 cannot fit in 1 bit and anything that remotely resembles a compiler knows that and would reject that.

That's just one of the _many_ problems with what FPC _pretends_ is a boolean.  Just taking the code from @ASerge, a boolean cannot index past 1 because it is limited to the values 0 and 1, yet in Serge's code a boolean is used as an index with the value 2.  This is even beyond what they can do at Cirque du Soleil.

It doesn't help that the behavior flies in the face of what the documentation states.  The documentation makes it very clear that a boolean is either zero or 1 and, it's quite obvious that is not the case.  If it were the case Serge's code could not output "error". 

Lastly, there is no amount of typecasting in the universe that can fit the value 72 (or any value greater than 1) in a single bit.  Yet one more proof that what FPC implements is NOT the boolean type but a bytebool (which it pretends is a boolean... obviously, with a lot of help from its friends who defend that atrocity.)

Of course, when all that FPC nonsense is pushed to its limits and falls apart, that's undefined territory.  I have to agree when something says that TRUE <> TRUE, that's definitely undefined territory and, it would have been very nice if it had also been never-discovered territory.  Stuffing values greater than 1 in what is by definition a single bit is not only undefined territory but quite a "breakthrough" (writable constants v2.0).

Anyway... it's rather obvious that we'll never agree just as it is obvious that FPC does not implement the boolean type. 

[TRon]

Anyway... it's rather obvious that we'll never agree just as it is obvious that FPC does not implement the boolean type.

fwiw I do not see eye to eye with everything you wrote but do agree that a boolean is just that: a boolean able to contain two different states.

I wonder how electronic engineers think about all of this

[Martin_fr]

You are repeating yourself. Still wrong. Please "slowly" reread my earlier posts. Thanks.

[Thaddy]

The only issue is really the optimization levels and fpc is not the only compiler that optimizes away its own definition. As I proved.

[440bx]

You are repeating yourself. Still wrong. Please "slowly" reread my earlier posts. Thanks.

I was hoping that repetition would lead to understanding, unfortunately, it doesn't always work, but, it's worth a try just in case.

They are completely wrong regardless of the speed at which they are read. 

You're very welcome!

[Zoran]

Found it, implicit and partially.
https://www.freepascal.org/docs-html/ref/refse85.html.

Thank you, Thaddy.
TRon pointed already to where it is actually documented, you obviously missed our posts (a few posts above), which is no surprise, this thread became hardly readable.

It's documented under Assignment operators, it appears that when assignment operator is defined, the compiler use it implicitly also with casting. Not only that, but the casting behaviour can be further redefined by overriding explicit operator.

[Thaddy]

I wonder how electronic engineers think about all of this

That is actually a good comparison to show the zero vs any other value is expected.
Problem is most cs think otherwise: strict low or high.

[Martin_fr]

You are repeating yourself. Still wrong. Please "slowly" reread my earlier posts. Thanks.

I was hoping that repetition would lead to understanding, unfortunately, it doesn't always work, but, it's worth a try just in case.

They are completely wrong regardless of the speed at which they are read. 

You're very welcome!

I was hoping if I use your terminology (i.e. "very slow") then that would make it more comprehensible to you.

Well, I admit when I was wrong. My assumption about using "very slow" was wrong. Apologies for that.

But well it happens, and one single mistake of mine in the entire thread, well I can live with that.

[440bx]

Well, I admit when I was wrong. My assumption about using "very slow" was wrong. Apologies for that.

But well it happens, and one single mistake of mine in the entire thread, well I can live with that.

You're making progress, you managed to see one of the times you were wrong.  In time you might see the many other ones too.

This is really good news... there is hope!  

Too bad there is no hope FPC will implement the boolean type correctly... oh well.  can't have it all I guess.

[Martin_fr]

Too bad there is no hope FPC will implement the boolean type correctly... oh well.  can't have it all I guess.

Correct: "will implement" reference to the future. They can't do it in future, as it already has been done. No mistake (not in fpc, nor of mine in writing this).

But maybe you have a secret different version of FPC? The one that I have behaves.

[440bx]

Correct: "will implement" reference to the future. They can't do it in future, as it already has been done. No mistake (not in fpc, nor of mine in writing this).

You're probably right that they can't do it in the future because if they were able to, they would have done in the past.

[Martin_fr]

Correct: "will implement" reference to the future. They can't do it in future, as it already has been done. No mistake (not in fpc, nor of mine in writing this).

You're probably right that they can't do it in the future because if they were able to, they would have done in the past.

Wrong mood. Not "would" but "did". Your welcome.

[440bx]

Wrong mood. Not "would" but "did". Your welcome.

You're just as correct as "Your welcome" which should be "You're welcome" but maybe it's just FPC English, like the FPC "boolean" thing. There is a resemblance but, it's still wrong.