API: Use C++ bool type for boolean values

[blarg]

In the C++ API, there are many member functions that appear to be boolean predicates, but they don't actually return a C++ bool, for example: ​http://www.gdal.org/classOGRSpatialReference.html#a519cce70fd39f974c61342bf73ab01ad

If these are intended to be boolean predicates, they should return a C++ bool. If they continue to return an int, then the callers need to check for returned values other than TRUE and FALSE, which complicates their code; and it's not clear to me how callers should react to an unrecognised returned value, of (let's say) 42.

Also, if these functions continue to return TRUE rather than C++ true, then the caller should explicitly compare the returned value against TRUE, in case TRUE one day gets redefined to a falsey value, further complicating their code.

We could add a new overload that returns bool, and deprecate the existing int overload, but if existing callers are (unwisely) simply testing the truthiness of the int, as if it were a bool, then that may not be necessary.

I intend to make this change in many tiny commits, in case I accidentally change a member function that wasn't actually a boolean predicate. But they could all be merged into one big commit if that were superior somehow.

[Even Rouault]

There are backwards implication in doing such changes. This should be discussed as a RFC, and probably for a GDAL 3.0

[blarg]

Ok. How do we proceed moving this discussion to an RFC? Sorry, I'm new to this project.

If we add a new bool overload, and leave the existing int overload(s) unchanged, that wouldn't create any backward-compatibility worries, right? Nobody would yet be calling the 'fixed' APIs.

[Even Rouault]

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to ​https://github.com/OSGeo/gdal/issues if it is not already reported there.