Is It Valid To Return Forward Declared Enum Class? (Visual Studio 2015 Linker Error)

Question

I have an issue where the following code compiles on GCC (4.8+ tested) and Clang (3.4+ tested) but does not compile on Visual Studio 2015 (VC++ 14.0).

Foo.h:

#include <functional>

namespace Error {
enum class Code;
static const Code None = static_cast<Code>(0);
}

class Foo{
public:
  std::function<Error::Code()> Run();
};

Foo.cpp

#include "Foo.h"
#include <iostream>

std::function<Error::Code()> Foo::Run() {
  return [&]() {
    std::cout << "hello\n"; 
    return Error::None;
  };
}

main.cpp:

#include "Foo.h"

namespace Error {
enum class Code {
  None = 0,
  Error = 1,
};
}

int main() {
  Foo foo;
  foo.Run()();
}

The resulting error in VC++ 14.0 is as follows:

Foo.obj : error LNK2001: unresolved external symbol "enum Error::Code __cdecl std::_Invoke_ret<enum Error::Code,class <lambda_813e82254384ef384f6a5fe34e885f01> &>(struct std::_Forced<enum Error::Code,0>,class <lambda_813e82254384ef384f6a5fe34e885f01> &)" (??$_Invoke_ret@W4Code@Error@@AAV<lambda_813e82254384ef384f6a5fe34e885f01>@@@std@@YA?AW4Code@Error@@U?$_Forced@W4Code@Error@@$0A@@0@AAV<lambda_813e82254384ef384f6a5fe34e885f01>@@@Z)

Which I believe is an internal std library function for implementng std::function.

This code is similar to usage of an internal library I'm trying to use that shares a standard program interface for tools, but forward declares Error Codes so they can be customized. I believe this should be valid code based on §7.2 (see this answer) The enum, though forward declared, should be a complete type and usable as a return value. Here is the relevant bit in the standard:

An opaque-enum-declaration is either a redeclaration of an enumeration in the current scope or a declaration of a new enumeration. [Note: An enumeration declared by an opaque-enum-declaration has fixed underlying type and is a complete type. The list of enumerators can be provided in a later redeclaration with an enum-specifier. —end note ]

Is this code valid? If so, is there a work around to get VC++ to accept it?

Answer 1

Yes, the code is valid.

This certainly does appear to be MSVC bug. I am able to reproduce this with a simple code sample;

func.cpp

#include <functional>
enum Code : int;
Code func2();
void func()
{
    std::function<Code()> f2 { func2 };
}

main.cpp

enum Code : int {
    Some = 0,
    Error = 1,
};
Code func2() { return Some; }
int main() {}

The error remains;

error LNK2019: unresolved external symbol "enum Code __cdecl std::_Invoke_ret(struct std::_Forced,enum Code (__cdecl*&)(void))" (??$_Invoke_ret@W4Code@@AEAP6A?AW41@XZ@std@@YA?AW4Code@@U?$_Forced@W4Code@@$0A@@0@AEAP6A?AW41@XZ@Z) referenced in function "private: virtual enum Code __cdecl std::_Func_impl,enum Code>::_Do_call(void)" (?_Do_call@?$_Func_impl@P6A?AW4Code@@XZV?$allocator@H@std@@W41@$$V@std@@EEAA?AW4Code@@XZ)

The error hints at an instantiation issue with std::function<Code()>, but no amount of explicit instantiation in either translation unit offers any resolution.

The error also does not seem dependent on the un-scoped enum vs. the scoped enum class.

The only work around at this time appears to be not using an opaque enum declaration at all, but to supply the full enum with its enumerators.

---

From Microsoft Connect (2016-05-09);

A fix for this issue has been checked into the compiler sources. The fix should show up in the future release of Visual C++.

Answer 2

Here are some more observations too large for a comment:

This is indeed a compiler bug, not a bug of the Standard Library implementation. The following program reproduces the same issue on VS2015 Update 1 without using the StdLib:

template<class T>
T create() {
    return {};
}

enum class Code;

int main() {
    create<Code>();
}

The linker complains about an unresolved symbol:

enum Code __cdecl create<enum Code>(void)

• The linker issue disappears if you leave out the return value (replace T with void).
• The problem remains when explicitly specifying the underlying type.
• The problem remains if we replace the scoped enumeration with an unscoped enumeration. We do not have to specify the underlying type when using Microsoft's C++ extensions (/Ze). Nothing changes when specifying the underlying type.

Answer 3

I think you should declare None in header (.h) and define it in source file(.cpp)

Foo.h

namespace Error {
    extern const Code None;
}

Foo.cpp

namespace Error {
    const Code None = static_cast<Code>(0);
}

Sometimes enum will be optimized and will have no instance or address, especially you declare it as a static variable.