AngelScript Bug: Nested Namespaces And 'using Namespace' Issue

Aug 16, 2025 by Omar Yusuf 63 views

Bug Report: `using namespace` Issue with Nested Namespaces in AngelScript

Hey guys! 👋 I'm super excited about the latest AngelScript release and the new GitHub repository – awesome work! 🎉 I've been playing around with the new features, and I think I might've stumbled upon a little bug related to the using namespace functionality. I wanted to share it here in case it's something that hasn't been spotted yet. (And if it's already a known issue, my apologies for the duplicate report! 😅)

The Issue: Nested Namespaces and `using namespace`

So, the problem seems to be that using namespace doesn't play nicely with nested namespaces. 🤔 Let me break it down with a code snippet. Basically, when you try to use using namespace with a namespace that's nested within another namespace, it doesn't seem to work as expected. It's like it can't quite find the functions within the nested namespace.

namespace A {
    void fn_a() {
        println('fn_a()');
    }
}

namespace A {
    namespace B {
        void fn_b() {
            println('fn_b()');
        }
    }
}

void main() {
    using namespace A;
    fn_a(); // OK

    B::fn_b(); // OK

    using namespace A::B;
    fn_b(); // [error] No matching symbol 'fn_b'
}

In this example, you can see that I've got a namespace A, and inside that, I have another namespace B. I can successfully use using namespace A to access functions within namespace A, and I can also directly access functions in B using the A::B:: prefix. However, when I try to use using namespace A::B, it throws an error saying it can't find the function fn_b. 😕

This inconsistent behavior makes working with nested namespaces a bit tricky. You expect that using using namespace A::B should bring the symbols from the nested namespace B into the current scope, but it doesn't seem to be doing that. This can lead to unexpected errors and make the code less readable, as you might have to use fully qualified names more often than you'd like.

The impact of this bug is that developers might need to avoid using nested namespaces or resort to fully qualified names, which can make the code more verbose and less maintainable. In larger projects with complex namespace structures, this issue could become a significant hindrance. Therefore, fixing this bug would greatly improve the usability and clarity of AngelScript code, especially in projects that leverage namespaces extensively.

Expected Behavior

Ideally, using namespace A::B should allow you to call functions within the B namespace directly, without needing the A::B:: prefix. This is how using namespace works for top-level namespaces, and it would be consistent and intuitive for it to work the same way for nested namespaces. Imagine how much cleaner and readable our code could be if this worked as expected! ✨

For instance, if we had several functions and classes within namespace A::B, being able to simply write fn_b() instead of A::B::fn_b() would greatly reduce clutter and improve the flow of the code. It would also make it easier to refactor code and move things around without having to update namespace prefixes everywhere.

The expected behavior aligns with the standard way namespaces are used in other languages like C++, where using namespace directives are commonly used to simplify code and improve readability. By supporting this behavior in AngelScript, developers can leverage their existing knowledge and best practices, making the language more accessible and easier to adopt.

Possible Causes

I'm not entirely sure what's causing this, but my hunch is that it might be related to how the compiler or interpreter resolves symbols when dealing with nested namespaces and using namespace. Perhaps there's a scope resolution issue, or maybe the lookup mechanism isn't correctly traversing the nested namespace hierarchy. 🤔

It's also possible that the using namespace feature was initially implemented with only top-level namespaces in mind, and the support for nested namespaces wasn't fully considered or tested. This is a common scenario in software development, where edge cases and less common scenarios might be missed during the initial implementation.

Another potential cause could be related to the internal data structures used to store and manage namespaces. If the structure doesn't efficiently support nested namespaces, it could lead to performance bottlenecks or incorrect symbol resolution. Understanding the underlying implementation details would be crucial in pinpointing the exact cause of this bug.

Potential Workarounds

For now, the workaround is to either avoid using nested namespaces (which might not be ideal in all situations) or to explicitly use the namespace prefix (e.g., A::B::fn_b()). This works, but it can make the code a bit more verbose, especially if you're frequently using functions from the nested namespace. 😕

Another workaround, although not as clean, could be to create aliases for the nested namespace or its members. However, this approach can quickly become cumbersome and hard to manage, especially if you have many nested namespaces or members to alias.

Ideally, we'd want a solution that allows us to use using namespace with nested namespaces as intuitively as we use it with top-level namespaces. This would greatly improve the coding experience and make the code more readable and maintainable.

Example Code

I've included the code snippet from above again for easy reference:

namespace A {
    void fn_a() {
        println('fn_a()');
    }
}

namespace A {
    namespace B {
        void fn_b() {
            println('fn_b()');
        }
    }
}

void main() {
    using namespace A;
    fn_a(); // OK

    B::fn_b(); // OK

    using namespace A::B;
    fn_b(); // [error] No matching symbol 'fn_b'
}

Environment

I encountered this bug in the latest version of AngelScript. I'm not sure if it's specific to a particular platform or operating system, but I'm running on [Your OS] with [Your Compiler/Setup].

It would be helpful to gather information from other users to see if this issue is reproducible across different environments and setups. This would help in narrowing down the potential causes and identifying any platform-specific issues.

Steps to Reproduce

Define a nested namespace structure (e.g., namespace A { namespace B { ... } }).
Declare a function within the nested namespace (e.g., void fn_b() { ... }).
In a function (e.g., main), use using namespace to import the nested namespace (e.g., using namespace A::B;).
Attempt to call the function declared in the nested namespace (e.g., fn_b();).
Observe the "No matching symbol" error.

These steps should consistently reproduce the bug, making it easier for developers to verify the issue and test potential fixes. Providing clear and concise steps to reproduce is crucial for efficient bug reporting and resolution.

Impact

This bug affects the readability and maintainability of AngelScript code, especially in projects that make heavy use of namespaces. It forces developers to either avoid nested namespaces or use fully qualified names, which can lead to more verbose and less clear code. In the long run, this can increase the effort required to understand and modify the code, potentially leading to errors and reduced productivity.

Suggestions

It would be fantastic if the using namespace feature could be extended to fully support nested namespaces. This would make the language more consistent and easier to use, especially for larger projects with complex namespace structures. A fix for this issue would be a huge win for AngelScript developers!

One possible solution could be to modify the symbol resolution logic to correctly traverse nested namespace hierarchies when processing using namespace directives. This might involve updating the internal data structures used to store namespaces and symbols, as well as the algorithms used to search for matching symbols.

Another approach could be to introduce a new syntax or mechanism specifically for importing nested namespaces, if the current using namespace syntax is deemed unsuitable for this purpose. However, this would need to be carefully considered to ensure it doesn't add unnecessary complexity to the language.

I'm really looking forward to seeing this resolved! 😊 Let me know if there's any other information I can provide or if you need me to test any potential fixes. Thanks for your time and dedication to making AngelScript awesome! ❤️