[Bug c++/52018] New: GCC refuses to accept a disambiguation statement

[Bug c++/52018] New: GCC refuses to accept a disambiguation statement

[piotr.wyderski at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52018

             Bug #: 52018
           Summary: GCC refuses to accept a disambiguation statement
    Classification: Unclassified
           Product: gcc
           Version: 4.6.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: piotr.wyderski@gmail.com


The following code:

class string {};

struct test {

    enum {

       string
    };

    void g(class string&& s) const {}

    template <typename... TA> void mth(TA&&... args) const {

        g(class string{std::forward<TA>(args)...});    
    }
};

compiled using GCC 4.6.1 and 4.6.2 fails:

$ g++ -std=gnu++0x -c test/test.cpp
test/test.cpp: In member function ‘void test::mth(TA&& ...) const’:
test/test.cpp:15:11: error: expected primary-expression before ‘class’

The Holy Book says:

3.4.4: "An elaborated-type-specifier (7.1.6.3) may be used to refer to a
previously declared class-name or enum-name
even though the name has been hidden by a non-type declaration (3.3.10)."

and the problematic statement:

    g(class string{std::forward<TA>(args)...});

looks like a reference.

[Bug c++/52018] GCC refuses to accept a disambiguation statement

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52018

Daniel Krügler <daniel.kruegler at googlemail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel.kruegler at
                   |                            |googlemail dot com

--- Comment #1 from Daniel Krügler <daniel.kruegler at googlemail dot com> 2012-01-30 08:56:28 UTC ---
The compiler behaves conforming: An elaborated type specifier is not allowed in
this context (see [expr.type.conv] p1 which says "A simple-type-specifier
(7.1.6.2) or typename-specifier (14.6) [..]", they are only allowed in
restricted context like a new expression for example. Note that similar
expressions apply more general type-specifiers like "unsigned int" which cannot
be used in such an expression. In other words: This does not look like a bug to
me. A reduced example would be the following snippet:

struct string { string(int); };

enum { string };

void h(struct string);

int main() {
  h(class string(42));
}

A simple workaround is to introduce a local typename-specifier:

typedef class string c_t;
h(c_t(42));

[Bug c++/52018] GCC refuses to accept a disambiguation statement

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52018

--- Comment #2 from Daniel Krügler <daniel.kruegler at googlemail dot com> 2012-01-31 07:33:25 UTC ---
(In reply to comment #1)
> A simple workaround is to introduce a local typename-specifier:
> 
> typedef class string c_t;
> h(c_t(42));

or use a static_cast (which has the additional advantage of not allowing a
silent reinterpret_cast):

struct string { string(int); };

enum { string };

void h(struct string);

int main() {
  h(static_cast<class string>(42));
}

[Bug c++/52018] GCC refuses to accept a disambiguation statement

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52018

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID

--- Comment #3 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-01-31 15:51:46 UTC ---
Closing then.