I use that "operator" as an easy tool to prevent off-by-one errors.

I'm open to hearing about why it's insidious, but have yet to hear a good reason. In debates with others, the only argument they offered up was "It's confusing to beginners" - but so is every other aspect of C++. If it confuses them, they can google or ask questions, and then it can forever cease to confuse them. It doesn't inherently lead to more complex or confusing code, like some C++ features do when abused.

Essentially, either someone understands it, or doesn't understand it.
If they understand it, there's no problem, and they move on.
If they don't understand it, clearly they would ask someone about it, google about it (and find instant explanations), and then henceforth they are a part of Group A and move on.

This "operator" isn't capable of being "abused", because anywhere you are using it is somewhere where you are already going to iterate backwards. It's not a code-flow issue. And, like I mentioned, it really is beneficial for reducing off-by-one errors - one of the most common source of bugs and security flaws in programming history, irrespective of language.

Here's a few functions from my code:
[rollup=Code from my codebase]
(this is a lower level function, that safer functions are built ontop of - which explains the use of raw strings and the same-size assumption)

inline bool StringCompare(const char *strA, const char *strB, unsigned size)
{
    //We go backwards, because it seems to me that strings are more likely to be similar
    //at the beginning of the string, and vary towards the end of it.
    //(For example, in a filepath, the first half or more might be identical)
    for(unsigned i = size; i--> 0;)
    {
        if(strA[i] != strB[i])
            return false;
    }

    return true;
}

//Compares two strings for equivalence, making the assumption that they are both the same length.
//'size' is the length of both strings. The comparison is case-insensitive.
//Returns true if they are both equal, and false otherwise.
inline bool StringCompare_CaseIn(const char *strA, const char *strB, unsigned size)
{
    //We go backwards, because it seems to me that strings are more likely to be similar
    //at the beginning of the string, and vary towards the end of it.
    //(For example, in a filepath, the first half or more might be identical)
    for(unsigned i = size; i--> 0;)
    {
        if(ToLower_Fast(strA[i]) != ToLower_Fast(strB[i]))
            return false;
    }

    return true;
}

Or here:

//Finds the last character in 'str', matching 'charValidatorFunc', starting backwords from 'pos' (if std::string::npos, then starting at the end of 'str').
//Returns std::string::npos if no character is found.
size_t FindLast(const std::string &str, CharValidatorFunc charValidatorFunc, size_t pos)
{
    if(pos == std::string::npos || pos > str.size())
        pos = str.size();

    for(; pos--> 0;)
    {
        if(charValidatorFunc(str[pos]))
            return pos;
    }

    return std::string::npos;
}

Or here: (error reporting of cyclic linking in config file DSL)

//Make sure we haven't already visited this file (we don't want infinite loops).
if(Contains(visitedFiles, filename))
{
    Log::Message message(MSG_SOURCE("ParseFile", Log::Severity::Error));
    message << "Recursive infinite loop detected, when trying to include " << Log_HighlightBad(GetFilenameFromPath(filename)) << ".\n"
            << Log::IndentUp << "#include " << Log_DisplayPath(filename) << "\n"
            << Log::IndentDown << "From: \n" << Log::IndentUp;

    for(size_t i = visitedFiles.size(); i--> 0; )
    {
        message << Log_DisplayPath(visitedFiles[i]) << "\n";
    }

    message << Log::FlushStream;

    return false;
}

[/rollup]

But I agree this one is really crazy :lol: , and rightly doesn't compile

while ( a --\
             \
              \
               \
                > 0 ){}

That compiles fine. Note that in C++, a backslash at the end of a line (if the very last character) hides the newline, making the following line parse as a single line.

For example:

//                          v--- backslash
#define Meow(kitty, kibble) \   
        std::cout << "The backslash extends the macro onto a second line." << "Also, kitties." << std::endl;

I'm open to hearing about why it's insidious, but have yet to hear a good reason.

That the -> operator is actually a thing

That's reasonable. I've never parsed it that way, but I can understand someone getting confused by that at first glance, especially the way I didn't have a space between the --> and my iterator.