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 :(

The script compiler is looking for

void Window::Open(string, uint32 style)

as oppose to

void Window::Open(uint32 width, uint32 height, uint8 bitsPerPixel, string title, uint32 style)

because you are calling

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

I never used AngleScript before, but my understanding it is basically c++. So I'm going to make an educated guess here.
In c++ you can't skip parameters 1,2,3 when just by providing 4 & 5 even though 1,2,3 has default values assigned.
Whereas if you provide 1,2,3 you can omit 4 & 5 like so:

MyWindow.Open(0,0, 32);

I have a hunch your script will compile if you do this:

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

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)

I see what you are saying, however that is not what the error message looks to be saying.

No matching signatures to 'Window::Open(const string, style: const Engine::WindowStyle)'

is because you calling

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

which is the signature of

void Window::Open(string, uint32 style)

Did you try doing what I suggested by calling

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

which is the signature of

void Window::Open(uint32 width, uint32 height, uint8 bitsPerPixel, string title, uint32 style)

I have one question about this line:

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);

Why are you putting your default values in the signature here in parameter 2?
Should it be like the following?

engine->RegisterObjectMethod("Window", "void Open(uint32 width, uint32 height, uint8 bitsPerPixel, string title, uint32 style)", as::asMETHOD(Window, Open_Call), as::asCALL_THISCALL);

Should the default values belong with the actual implementation be like this

void Window::Open(uint32 width = 0, uint32 height = 0, uint8 bitsPerPixel = 32, string title = "\\", uint32 style = 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.

I feel sheepish because I misread the intent of this entire post.
My context was that the OP was asking for a solution as oppose to showcasing a problem.
Because of that I wasn't able to pickup what Wipe was telling me that he intentionally wrote a broken script to showcase the problem.
Then I doubled down like a fool when I shouldn't have.
Sorry Wipe.