By the way: HIGH can also be either 'true' or 'false', as well as LOW. Arduino uses the notation HIGH=1 and LOW=0 with no indication of the data type used.
And that comes from Unix which M$ version was XENIX which as all C-based OS use "0" for "no error" and anything other than 0 as "ERROR". M" has to break code when they jumped ships ... Anyway, it teaches you the hard way that x==1 is a bad idea - or not, but you have to read the docs.
A quote:
OK, let's get really pedantic. (Doc did say he was splitting hairs.)
In fact there are no numbers in computers at all. There are nothing but arrays of True and False. As a single bit, True is interpreted as 1 and False as 0 in binary notation.
In Access, Boolean True is represented by setting every bit in the byte to True. (Or in the case of 64 bit memory the bits in all four bytes are set to True). You can't get any Truer than that.
It just so happens that all bits True in Two's Complement binary notation represents minus one. True is not stored as minus one.
I will further emphasise this by comparing the bit datatype in SQL Server. In this environment, True is also stored as True in a single bit as part of a byte. A single byte stores up to eight independent bit fields. Hence SQL Server returns 1 for True because it does not represent minus one.
From this page:
True Comparison Expression returns -1, why? | Access World Forums.
So that’s how that came to be
I seem to recall a long time ago using a program where false was -1 and true was any positive integer. It may have been in Turbo C that I fiddled around with for a couple of weeks many years ago.
Anywho, I will take the risk that in the unlikely chance that I interface with a database to run something in the real world that I will have to break a nasty habit I have developed.
Also: (Or in the case of 64 bit memory the bits in all four bytes are set to True). should be 8 bytes. So now I am more pedantic than the author of the post
That is just arbitrary. It would be just as valid to interpret 0 as true and 1 as false
come on, it's not being a pedant (a person who is too interested in formal rules and small details that are not important). This is misleading. understanding types in C++ is super important.
You might have missed (because of the topic split) the origin of the conversation, but we were debating with @zwieblum the value of strong typing for building scalable and maintainable applications.
My point was that strong typing and honouring types / API is an integral part of quality code (and thus not just a thing for the pedants).
Those coming (like me) from a C background are used to bool not being a formal type and just a convenience for 0 (false) and non 0 (true). This is no longer the case in C++, the truth type does exist (with implicit integral promotion to 0 and 1 and implicit promotion for 0 / non zero to maintain compatibility with C and exiting code).
And the proof of the pudding is in the eating ➜ This happened in our ecosystem.
Another example of not understanding the role of types : how often do we see issues here because posters ask why the maths don't work on UNO when they do
unsigned long oneHour = 60 * 60 * 1000; // in ms. 60 minutes of 60 seconds, 1000ms in a second.
to get this you need to know the C++ language says it uses a type large enough to represent the integral literal so 60 and 1000 become int and then the math is conducted using int which is 2 bytes on that platform and you overflow (yes the compiler will tell you but newbies did not pay attention) and you get the wrong duration for oneHour
And let's not open again the type punning / memcpy() discussion.
Anyway, I'm fine if you stick to the "it works and will keep working so I don't care" philosophy, but this does not give you the right to judge others who don't see it this way and call them pedants (with its pejorative connotation).
my 0.02€
IMO this line
digitalWrite(digitalRead(pin) == LOW ? HIGH : LOW);
is for beginners to Arduino completely incomprehensible, convoluted tohuwabohu. OTOH, I do not even recognize which output pin had to be set at all.
1st, I am pretty sure that the compiler makes the same bin codes out of
if( digitalRead(pin)==true )
vs.
if( digitalRead(pin) )
2nd, for beginners (who perhaps would need this lesson) it would be much more intuitively understandable to write
if(digitalRead(pin)==true) digitalWrite(outpin, LOW);
else digitalWrite(outpin, HIGH);
or even:
digitalRead(pin)? digitalWrite(outpin, LOW) : digitalWrite(outpin, HIGH);
just my2ct.
Ha! You just don't dare to admit that you started with BASIC! 
Joke aside, most older members have seen an other world of programming long gone by. And none of the languages since the dawn of time deliverd the silver bullet.
I did....
You could simply use bitfields, they exist in C, too.
@ J-M-L:
coming from a C background, bool type is provided by <cstdbool> (stdbool.h).
As to C++ (which is used by Arduino), bool is an integrated fundamental datatype.
Converting true to an integer type will yield 1, and converting false will yield 0, it's not just sort of #define ....
(CMIIW)
Don't use it if you don't like it, simple as that.
Guess what's in stdbool.h:
#define true 1
#define false 0
Funny fact on g++: bool is implemented as byte, no matter what optimisation you turn on 
YMMD 
I can agree with the complexity of the ternary but I'm totally against the way you wrote it.
The spec says digitalRead returns HIGH or LOW, not a boolean.
so I'm OK with
if (digitalRead(outpin) == HIGH) {
digitalWrite(outpin, LOW);
} else {
digitalWrite(outpin, HIGH);
}
that's what I said, isn't it?
We are talking about Arduino code, and so it's about C++, not C, and in C++ it's a fundamental datatype, not a #define makro.
at least you didn't state it absolutely clearly.
nope, truth to be told Fortran was my first language.
@ J-M-L:
fair enough as to digitalRead().
Nonetheless I'm curious how Arduino actually defines the returned values HIGH or LOW e.g. by digitalRead().
perhaps the crucial question might be:
what is the exact difference in the binary codes that gcc (g++) generates from the following code snippets:
if( digitalRead(pin) )...
if( digitalRead(pin)==true )...
if( digitalRead(pin)==HIGH)...
and
if( !digitalRead(pin) )...
if( digitalRead(pin)==false)...
if( digitalRead(pin)==LOW)...