If you set the includeNamespace bool to true on GetTypeDeclaration(), you get a "::" prepended on types which are logically not in a namespace:

class Foo {}

// GetTypeDeclaration() returns "::Foo"

This seems like an internal implementation detail.. logically class Foo is not in a namespace.

Would you consider changing this to not include the '::' for a type which is not in a user-defined namespace?

Thank you.

This seems like an internal implementation detail.. logically class Foo is not in a namespace.

Just a technical side note: actually Foo is in a namespace, the "global namespace". thus the prepended "::". This is also true for C++, thats why you can reference global stuff by typing "::", just check your intellisense ;)

actually Foo is in a namespace, the "global namespace"

You're right, of course, but look at how C++ deals with this:

#include <iostream>
#include <string>
#include <typeinfo>

class Foo {};
Foo foo;

namespace ns
{
    class Bar {};
}
ns::Bar bar;

int main()
{
    std::cout << typeid(foo).name() << std::endl;
    std::cout << typeid(bar).name() << std::endl;

    return 0;
}

# g++ typeid.cpp -o typeid && ./typeid | c++filt -t
Foo
ns::Bar

You're right, of course, but look at how C++ deals with this:

Sure, there is a difference, but I personally don't have any opinion on whats the "correct" or better way here. I just wanted drop in a quick explanation in case there was any technical confusion. If you want me to quess, I'd say c++ purposely dropps the "::" on any global namespace class, because I think internally global or user-defined namespaces are handled somewhat the same.. but thats just quessing. Andreas can surely answer you why it currently is that way and if he decides to change it ;)

The :: makes it explicit that the symbol is declared in the global namespace. In my opinion it is correct to include it when you request to know the namespace of the symbol.

If you want to remove it for aesthetic purposes, then it is easy to check if the returned string starts with :: and just skip that.

Fair enough.

The :: makes it explicit that the symbol is declared in the global namespace

That's technically correct, but I don't think that's a distinction that matters for many/most use-cases. For example, all my app-registered classes are within a namespace (e.g. myns::MyType). If I have such an instance and I request the namespace from GetTypeDeclaration(), that's because I'm trying to get "myns::MyType" - without 'includeNamespace', I get "MyType", which is not what I'm looking for. This is the reason I'm requesting namespaces, not because I want to be technically 100% correct and get the :: prepended.

It's so ugly even C++ doesn't do it!!!! You can't argue with that :)

I had a similar issue recently involving asIScriptFunction::GetDeclaration. While personally I certainly don't mind it explicitly stating the global namespace, it appeared as if asIScriptModule::GetFunctionByDecl was unable to interpret it. That means that neither including nor omitting the namespace always allows for identification of a function. Additionally, in this case the redundant "::" could prove more difficult to find and remove if one were to do that by hand, because it doesn't directly precede the string (and there could potentially be more occurrences of it, e.g. consider "foo::bar ::function(foo::bar)"). What I ended up doing was

asFunction->GetDeclaration(true, asFunction->GetNamespace()[0] != '\0', false)

which, honestly, looks like a terrible hack, but works. Either way, if not getting rid of the explicit preceding scope resolution operator, I would suggest at least modifying GetFunctionByDecl and possibly other similar functions accordingly, as they should most certainly be able to interpret declarations returned by other library functions.

That is a more convincing argument :)

I'll make the change. And I'll also look into GetFunctionByDecl (and similar functions) that definitely should be capable of understanding namespaces.

I've changed this in revision 2044.