'local::' ns prefix to refer to project's default namespace

[LordZoltan]

This suggestion stems from a build failure I encountered today:

In Company.Product/Extensions.cs :

using Company.Product;
namespace Company.Common
{
  public static class Extensions
  {
    public static void DoSomething(this Baz obj)
    {
      var a = Foo.Bar(obj); //CS7227
    }
  }
}

And in Company.Product/Foo.cs:

namespace Company.Product
{
  public class Foo {
    public static object Bar(Baz obj)
    {
      // stuff
    }
  }
}

And the referenced Company.Common project declares:

namespace Company.Common.Foo
{
  // stuff...
}

So we have a common library with the namespace Company.Common.Foo, and another project Company.Product that declares a set of extension methods which merge directly into Company.Common.Foo, but which reference a class Foo that is defined in that project.

The compiler error is that the namespace Company.Common.Foo doesn't contain a type Bar. And of course it doesn't :)

I know this is not a bug - but the fix is either to alias Company.Product.Bar or to namespace-qualify it on the offending line as var a = Company.Product.Bar(obj);

In reality, the namespace involved were longer and more nested - and the functions/types involved are more logical and useful than these examples!

Proposal

A local:: namespace prefix which acts as an alias to the default namespace of whichever project the code file is being compiled within.

The above error could then be fixed with

var a = local::Bar(obj);

[HaloFour]

There is no "default namespace" to the C# compiler. The project option exists only for tooling in Visual Studio and the build system.

I could see using local:: as an automatic alias fir the current assembly but you'd still be required to bring the actual namespace in scope.

[jnm2]

local:: feels dirty compared to using an alias. You could even do Local.Bar if you really wanted to use the word local.

[LordZoltan]

Fair comments.

Although I'm not sure I buy the argument that local:: is dirty but global:: isn't...

Equally - yes, of course I can add an alias instead to sidestep the problem. But the same is true of the global:: prefix wherever I'd need to use it.

As a 'standard' alias, though - it seems to me something that could be achieved using a source file rewrite as part of Roslyn's compilation process (although I confess I don't even know if that's possible right now): A property fed into the compilation containing one or more namespaces with aliases which are then automatically rewritten into the parsed code file's using statements. When MSBuild builds a file from a project - it automatically picks up the project's RootNamespace property and adds that namespace as Local by default (or some other special name that's less likely to clash with 'standard' code).

[jnm2]

I only say local:: seems dirty because global:: does, though unlike global:: I guess local:: has the added downside that it is no longer possible to know what it means when looking at a single source file. You either have to be familiar with the codebase or go searching in the .csproj. The C# team has repeatedly made a point of avoiding that kind of syntax.

[HaloFour]

I don't think it would be dirty. You can already name those aliases whatever you want per reference and that naming is external to the source. The "global" alias just happens to be the default. I don't really see an issue adding a "local" alias as well that would restrict resolution specifically to the current assembly as long as it wasn't used to alias some other reference. But that alias the namespaces themselves, just the assembly:

using FooProduct = foo::Company.Product;
using BarProduct = bar::Company.Product;
using MyProduct  = local::Company.Product;

[jnm2]

@HaloFour Right. If the full namespace is contained in each file, I have no problem with it.