Is there a bug with parsing member access expressions on a user-defined integer literal in Clang and GCC? [duplicate]

Question

When compiling this code (without any header)

template <typename T>
struct Temperature {
    T temp;

    explicit Temperature(T t)
        : temp(t)
    {}
};

Temperature<long double> operator "" _f (long double t)
{
    return Temperature<long double>((t - 32) / 1.8);
}

int main()
{
    auto t = 100.0_f;
    t.temp;

    100.0_f.temp; // ERROR AT THIS LINE
    return 0;
}

The compilers (both g++ 4.8 and clang++ 3.4 on Ubuntu 14.04) will complain that

error: unable to find numeric literal operator ‘operator"" _f.temp’
     100.0_f.temp;
     ^

It seems that the _f.temp is considered as a suffix there. Why do the compilers parse it like that, instead of stopping at the dot?

Answer 1

Preprocessing numbers are odd beasts, specified mostly to make the preprocessor easier to write.

pp-number:
    digit
    . digit
    pp-number digit
    pp-number identifier-nondigit
    pp-number ' digit
    pp-number ' nondigit
    pp-number e sign
    pp-number E sign
    pp-number p sign
    pp-number P sign
    pp-number .

12 is a valid pp-number token, so is 0xe+foo (see the example in [lex.pptoken]/4), and so is .12.CA'TS_RULE..56.me+owp-urr. If the latter two make it past translation phase 6, then the program is ill-formed because it cannot be converted to a valid token in phase 7. Until then, however, it is valid, so maximal munch says we parse 0xe+foo or 100.0_f.temp as a single preprocessing token.