When compiling function which uses enum value as default argument, and compiler needs to write message with function declaration, it omits enum namespace and puts spaces around `::`

Registration

engine->SetDefaultNamespace("Engine");

engine->RegisterEnum("WindowStyle");
engine->RegisterEnumValue("WindowStyle", "None", sf::Style::None);
engine->RegisterEnumValue("WindowStyle", "Default", sf::Style::Default);

engine->RegisterObjectType("Window", 0, as::asOBJ_REF | as::asOBJ_NOHANDLE);
engine->RegisterObjectMethod("Window", "void Open(uint32 width = 0, uint32 height = 0, uint8 bitsPerPixel = 32, string title = \"\", uint32 style = WindowStyle::Default)", as::asMETHOD(Window, Open_Call), as::asCALL_THISCALL);

engine->SetDefaultNamespace("");

Bad script

MyWindow.Open("", style : Engine::WindowStyle::None);

Error message

Compiling bool testEnumThing()
No matching signatures to 'Window::Open(const string, style: const Engine::WindowStyle)'
Candidates are:
void Window::Open(uint width = 0, uint height = 0, uint8 bitsPerPixel = 32, string title = "", uint style = WindowStyle :: Default)

…And when i look at that message again, there's no namespace displayed for function itself as well :(

Script is intentionally wrong to force error message to show up ? Problem here is just an alien way of printing function declaration by compiler, nothing more

What i get

void Window::Open(uint width = 0, uint height = 0, uint8 bitsPerPixel = 32, string title = "", uint style = WindowStyle :: Default)

What i expect

void Window::Open(uint width = 0, uint height = 0, uint8 bitsPerPixel = 32, string title = "", uint style = WindowStyle::Default)

Or better yet

void Window::Open(uint width = 0, uint height = 0, uint8 bitsPerPixel = 32, string title = "", uint style = Engine::WindowStyle::Default)

Nop, AngelScript have no way to figure out what default arguments on C++ side are, plus you might want scripts to use different values for default arguments. Or function arguments which have no defaults on C++ side can use some default arguments in scripts. Or the other way around! :>

And that's great, as you don't even have to touch implementation to provide script function(s) which are slightly different in default arguments business. That's a blessing when, for example, you're exposing functions coming from 3rd party library which you can't or simply don't want to touch.

@Wipe, thanks for letting me know about the error message. I'll look into it. Though as it is just aesthetic it will be low priority.