CODEWITHSUNDEEP
c++c-preprocessortokenlanguage-lawyerrvalue-reference
Trevor Hickey
Trevor Hickey

Reputation: 37816

Why isn't bitand properly parsed to form an rvalue reference?

An rvalue reference could be formed using an alternative token: 

int and i = 0;

It could also be formed after splicing physical source lines to form logical source lines: 

int &\
& i = 0;

So why doesn't the following program compile? 

int main() {
    int &\
bitand i = 5;
}

Based on the standard, I don't see why it shouldn't.

[lex.digraph] In all respects of the language, each alternative token behaves the same, respectively, as its primary token, except for its spelling.

[lex.phases] Each instance of a backslash character (\) immediately followed by a new-line character is deleted, splicing physical source lines to form logical source lines. Only the last backslash on any physical source line shall be eligible for being part of such a splice.

Is there additional information that I missed, or is this a compiler bug?

Upvotes: 2

Views: 61

Answers (1)

n. m. could be an AI
n. m. could be an AI

Reputation: 119857

The backslash+newline sequence is a red herring. These things are removed before the tokenization phase (that's phase two and phase three of the translation, respectively). We can thus concentrate on these fragments instead:

&&
&bitand

The first line has one token, &&. The second line has two tokens, & and bitand. The last token is equivalent to & so the second line behaves exactly as if it contained two & tokens. This is different from one && token. The latter is composed of two & characters, not two & tokens.

Upvotes: 4

Related Questions