Must &= always be interpreted as an operator?

Question

I was coding and accidentally left out a space between a constant reference and its default value. I was surprised to see that it came up as an error in Intellisense, so I compiled it, and sure enough, it doesn't work in GCC 4.3.4, 4.5.1, or 4.7.2, and doesn't work in Visual Studio 2012, either.

Here's an equivalent sample that demonstrates the error:

struct S {
    S(const int &= 5){}    
};

int main(){}

This yields the following error in GCC, and similar ones in MSVC:

error: expected ',' or '...' before '&=' token

I presume this is because &= is being treated as an operator, but I don't know exactly what to search for in the standard to find more information about this case. &= just comes up with operator-specfic information.

Being curious, I decided to swap it out for an rvalue reference:

S(int &&= 5){}

Strangely enough, this compiles fine on both GCC 4.7.2 and MSVC, which means that &= isn't always lexically paired as an operator.

Why does it work with an rvalue reference, but not an lvalue reference, and what does the standard have to say on the matter?

Answer 1

This is generally known as the "principle of longest match", or the "maximal munch". Because && is a valid token and &&= is not (there's no compound-assignment notation for &&), the longest token that &&= starts with is &&; after that's been removed, there's no opportunity for &= to be seen as a single token.

This principle is common to many languages, though there are often exceptions to it. For example, in C++11, >> will be analyzed as > followed by > in a context like std::vector<std::vector<int>>.

Answer 2

The parser just works left to right, regardless of associativity, so in the first example, the first full token it finds is the &=. (At that moment, the parser doesn't check for larger constructs yet, so all it knows is that there's that token there.)

In the second example, the token it finds is &&. Because &&= is not a token!