Namespaces

9 Namespaces

As in C++, namespaces are used to avoid name clashes in code. For example:

  namespace Foo { 
    int x = 0; 
    int f() { return x; }  
  }

declares an integer named Foo::x and a function named Foo::f. Note that within the namespace, you don't need to use the qualified name. For instance, Foo::f refers to Foo::x as simply x. We could also simply write ``namespace Foo;'' (note the trailing semi-colon) and leave out the enclosing braces. Every declaration (variables, functions, types, typedefs) following this namespace declaration would be placed in the Foo namespace.

As noted before, you can refer to elements of a namespace using the ``::'' notation. Alternatively, you can open up a namespace with a ``using'' declaration. For example, we could follow the above code with:

  namespace Bar {  
    using Foo { 
      int g() { return f(); } 
    } 
    int h() { return Foo::f(); } 
  }

Here, we opened the Foo namespace within the definition of Bar::g. One can also write ``using Foo;'' to open a namespace for the remaining definitions in the current block.

Namespaces can nest as in C++.

Currently, namespaces are only supported at the top-level and you can't declare a qualified variable directly. Rather, you have to write a namespace declaration to encapsulate it. For example, you cannot write ``int Foo::x = 3;.''

The following subtle issues and implementation bugs may leave you scratching your head:

The current implementation translates qualified Cyclone variables to C identifiers very naively: each :: is translated to _ (underscore). This translation is wrong because it can introduce clashes that are not clashes in Cyclone, such as in the following:
```
  namespace Foo { int x = 7; }
  int Foo_x = 9;
```
So avoid prefixing your identifiers with namespaces in your program. We intend to fix this bug in a future release.
Because #include is defined as textual substitution, the following are usually very bad ideas: Having ``namespace Foo;'' or ``using Foo;'' at the top level of a header file. After all, you will be changing the identifiers produced or the identifiers available in every file that includes the header file. Having #include directives within the scope of namespace declarations. After all, you are changing the names of the identifiers in the header file by (further) qualifying them. Unfortunately, the current system uses the C pre-processor before looking at the code, so it cannot warn you of these probable errors.

In short, you are advised to not use the ``semicolon syntax'' in header files and you are advised to put all #include directives at the top of files, before any namespace or using declarations.
The translation of identifiers declared extern "C" is different. Given
```
  namespace Foo { extern "C" int x; }
```
the Cyclone code refers to the global variable as Foo::x, but the translation to C will convert all uses to just x. The following code will therefore get compiled incorrectly (f will return 4):
```
  namespace Foo { extern "C" int x; }
  int f() {
    int x = 2;
    return x + Foo::x;
  }
```