Get rid of boolean type; use bool instead

[cousteaulecommandant]

Is there a need for the boolean type at all, other than backwards compatibility?

Currently, Arduino's boolean type is defined as an alias to bool (thanks, Chris--A!). However I don't see the need to have a custom boolean type when C and C++ already provide one.
Advantages of the bool type are:

• it is shorter
• it is standard
• it is consistent with other "abbreviated" C and C++ types such as int and char

I think it would be a good idea to stop using this custom boolean type and instead use the bool one; in my opinion, the fewer unneeded additions Arduino makes to the language, the better.
The steps for moving would be (in this order):

• Replace all boolean from Arduino core and library functions with bool.
• Update the documentation, removing all references to boolean and replacing them with bool (and maybe adding a note that the boolean type is deprecated).
• State that the boolean type is deprecated. An __attribute__ ((deprecated ("use bool instead"))) on the boolean definition could be a good idea.
• Eventually, a few versions after deprecating boolean, consider its removal. (Or leave it there forever, just in case.)

[NicoHood]

I agree fully with your idea and down want to repeat them, cause they are exactly what I think too.

[matthijskooijman]

Sounds like a good plan. Might be good to do this at a 1.7/1.8 release, not in a point release, though. I guess this also ties in with #4525 a bit.

[matthijskooijman]

Sounds like a good plan. Might be good to do this at a 1.7/1.8 release, not in a point release, though. I guess this also ties in with #4525 a bit.

Also, using the deprecated attribute is a good plan (we should consider doing that more often) and apparently it actually works on typedefs too.

[NicoHood]

Yo we should also use the depreciated thing for SerialEvent.

[per1234]

Is anyone against changing all usage of boolean in the Arduino cores, Arduino libraries, and example sketches to bool, accompanied by the same change in the reference pages? I'm willing to submit pull requests for the code changes but would like to get an idea if there are any objections first because it means multiple PRs to the various repos and I wouldn't want to make a lot of "noise" for something that is not actually wanted. I can't make the documentation changes but I can provide a list of all pages that need editing.

If that's considered too abrupt a change we could ease into it by first adding a note to https://www.arduino.cc/en/Reference/BooleanVariables and removing boolean only from library code but not from examples. Then making the rest of the change after some months delay. I'm not sure whether that would be terribly effective, probably better to just make the full change all at once.

I'm against ever actually removing the boolean typedef. Maybe it never should have been done in the first place but now it's used in so much code that removing it would cause massive problems.

[NicoHood]

Just do the full switch and add a depreciated pragma so users start switching their code. It really causes less errors and confusion.
https://msdn.microsoft.com/en-us/library/c8xdzzhh.aspx

[cousteaulecommandant]

@NicoHood that link is for VisualStudio though; not sure if that pragma works for GCC as well. GCC uses __attribute__ ((__deprecated__)).

[Pharap]

In case there's any confusion of how deprecating things works in either compiler, there's an example here of someone marking type aliases as deprecated with both GCC and MSVC (Visual Studio).

(Sadly had we been at the stage where most compilers were C++14 compliant it would have been as simple as [[deprecated("don't use boolean, use bool")]] instead.)

For now it's probably alright to just have the compiler detection boilerplate around where boolean is being declared (following a YAGNI approach), but if more things ever need deprecating in the future it might be better to define a DEPRECATED(name) macro with a different definition depending on which compiler is present (following a DRY approach).
(It would unfortunately mean introducing a new symbol that might leak out into user code, but having a large chunk of compiler-detecting code around everything that's ever deprecated is probably just asking for typos.)

@per1234 If people opt for the 'ease it in' option, I think the examples should still be changed along with the library code. Users should be given warning that the change is going to happen, but it should be made clear that it's going to happen and there's no backing out of it. Plus any new users who learn from those examples should be being taught the newly preferred approach, not the soon-to-be-deprecated approach (which will soon be giving them 'scary' warnings).

[matthijskooijman]

I would welcome a switch to the standard bool type, though in the end I think @cmaglie or @facchinm should comment whether they would want to merge such a change.