Ability to reuse type alias in another assembly with apply all encapsulation limitation

[soroshsabz]

ITNOA

As you know in C# language we cannot use using alias in another assembly or in another using alias.

In another word, we cannot using using alias as normal type, that transparent type declaration for users. this feature exist in C++ for many years, and it is very useful specially in generic complex type aliasing.

for example I want to have something like below

namespace UsingTest
{

    public interface IUsingTest
    {
        using MyType = System.Collections.Generic.List<System.Collections.Generic.Dictionary<string, int>>;
        MyType GetList();
    }
}

and in another class (in same assembly or in another assembly) we want to use this type is natural way like below

namespace ConsoleTest
{
    internal class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Hello, World!");

            UsingTest.IUsingTest.MyType foo = UsingImplementaiton.GetList();
        }
    }
}

or in another use case, I want to add scope to using alias in class inheritance model for example

class Foo
{
   public using MyType = List<int>;
   protected using OnlyChildType = Dicitonary<int, MyType>;
};

the public using alias provide this type globally for all users of Foo class, but protected using alias provide this type only for derived classes.

in the end, I think if using alias behave like using in C++ we can provide a better abstraction and encapsulation and decoupling of codes.

thanks

[HaloFour]

I believe that this will fall out with extensions: #5497

Explicit extensions specifically allow for a zero-cost abstraction for a subtype of any existing type that can provide type safety and additional functionality through extension members.

[soroshsabz]

@CyrusNajmabadi what is your opinion?

[kasajian]

@HaloFour I very much agree with the statement that without type-safety, it's not as useful. In C typdefs have this problem, and we have to play games with hidden structs (such as how HWND is defined in win32 strict mode). I think there are types when you want simply have a different name for the existing type. In C this was very useful for instance I want to have type INT32 and INT16 to always be 32-bit and 16-bit, and typedef would map to the appropriate type for the particular hardware.

I can't think of very good examples where that's needed in C#. Some of this reminds me Nominal types in Typescript where even two independent interfaces are basically the same type as far as the compiler is concerned, if their struct is identical.

What you're talking about our ValueObjects, and probably the #1 feature missing for me in C#. What you really want is something like Vogen but built-in: https://github.com/SteveDunn/Vogen

[Richiban]

Explicit extensions specifically allow for a zero-cost abstraction for a subtype of any existing type that can provide type safety

Do extensions allow "constructors"? I.e. for a public explicit extension SpecialPerson for Person can I make the conversion from Person to SpecialPerson fail with an exception if certain conditions are not met?

[HaloFour]

See: #8161

Per the Discord conversations, the team is very interested in "validation" for explicit extensions.

[Richiban]

See: #8161

Per the Discord conversations, the team is very interested in "validation" for explicit extensions.

That's great to hear, cheers!

[soroshsabz]

related to #4284
related to #1239