Allow forward declaring a type outside the present namespace

[jpg85]

Since bond files can only declare a single namespace, forward declaring objects in other namespaces becomes tedious. While it may seem odd to need to forward declare an object in another namespace, when using custom aliases, the type may never be defined in bond. However, to keep the bond compiler happy, the type must exist.

An alternative would be to allow a scoped namespace declaration.

[chwarr]

I was following along until the custom alias part. 😀 Can you post a more concrete example with an alias interaction. Feel free to make up syntax. That will help me understand this pain point better. Thanks!

[jpg85]

namespace foo

struct .bar.ext;

struct obj
{
    0: handle<bar.ext> ext_obj;
}

I use a custom alias to define what "handle" is. It actually gets serialized/deserialized as a scalar type, but I want the generated structures to contain the "bar.ext" object. The aliased type on one side is a pointer, so it doesn't need to be defined, and the aliased type on the other side is a generic template that doesn't care about the actual type.

Presently, I can accomplish the above by creating a separate "bond" file that declares a namespace "bar" and then forward declares an object "ext". This gets tedious when defining multiple types in multiple namespaces.

[chwarr]

Gotcha. Thanks!

gbc could be extended to understand that something like struct x.y.z; is a forward declaration of a struct z in the namespace x.y; It think this can be accomplished by a change in the parser for a forward declaration. Instead of always getting the current namespace and reading a single identifier, instead, read using the qualifiedName parser (after fixing a bug in it). If the result is a singleton list, use the current namespace for the declaration's namespace. Otherwise, the declaration's name is the last element in the qualified name list, and the namespace are the first n - 1 elements.

There appears to be a bug in the implementation of qualifiedName. The comment for qualifiedName implies that is can be used to parse an optionally namespace-qualified declaration name, and it is used in places where that is wanted. It's current implementation reads a sequence of namespaceIdentifier values (which allow an element with the name "Schema") separated by periods.

However, in struct/enum/view definitions, the name is parsed by identifier (which does not allow "Schema").

Thus, a proper implementation of qualifiedName should be an optional sequence of period-separated namespaceIdentifiers followed by a required identifier. The parser for namespace would need to be adjusted to use something other than qualifiedName.

This isn't something that we need inside of Microsoft; we won't be implementing it any time soon. You are welcome to contribute it.

---

Related: Issue #359, "Multiple Namespaces per IDL file"

That issue mentioned that support for multiple namespaces could not be added there was internal Microsoft tooling that wouldn't be able to handle such a change. That tooling is still around, but in the three years since that issue was opened, its use has declined enough that maintaining backward compatibility with it is probably no longer needed. This change would be similar.

[jpg85]

Thanks. This issue is less important to us as well. I'll keep it open for anyone curious in the future and maybe by that time I'll find a way to contribute.