Add typedef-like functionality to simplify type aliasing across namespaces

[XmmShp]

Problem Statement:

Currently, C# provides limited support for type aliasing through the using directive (e.g., using MyType = SomeNamespace.SomeType;). However, this approach has several limitations:

1. File Scope Only: Aliases defined with using are scoped to a single file unless combined with global using (introduced in C# 10, but it doesn't support generic type). This makes it cumbersome to define and maintain aliases across large projects.
2. No Cross-Namespace Support: It is not possible to create an alias that spans multiple namespaces while preserving the original type's static methods, properties, and other members.
3. Conceptual Separation: In some cases, two types may have identical structures but represent different concepts in the codebase. For example, Response and Result might be structurally identical but conceptually distinct. A developer-friendly way to alias these types would improve code readability and maintainability.

Proposed Solution:

Introduce a new typedef-like feature inspired by TypeScript's type keyword. This feature would allow developers to define type aliases that:

1. Work Across Namespaces: The alias can reside in a different namespace from the original type.
2. Preserve Static Members: The alias should behave identically to the original type, including access to static methods, properties, and extension methods.
3. Be Globally Scoped: The alias can be defined once and used throughout the project without needing to repeat the definition in every file.

Example Use Case:

Suppose we have two classes, Response and Result, which are structurally identical but conceptually distinct:

namespace Api.Models
{
    public class Response<T>
    {
        public string Message { get; set; }
        public T Value { get; set; }
    }
}

namespace BusinessLogic.Models
{
    public class Result<T>
    {
        public string Message { get; set; }
        public T Value { get; set; }
    }
}

Currently, if we want to treat these as interchangeable in certain contexts, we must manually manage conversions or use verbose type names. With the proposed typedef-like feature, we could define:

namespace BusinessLogic.Models
{
    typedef Result<T> = Api.Models.Response<T>;
}

This would allow developers to use BusinessLogic.Models.Result interchangeably with Api.Models.Response while maintaining conceptual clarity.

Benefits:

1. Improved Readability: Developers can use domain-specific type names that better reflect the context in which they are used.
2. Reduced Boilerplate: Avoids repetitive type conversions or verbose type definitions.
3. Enhanced Maintainability: Changes to the underlying type (e.g., renaming or refactoring) only need to be made in one place.
4. Cross-Namespace Flexibility: Enables cleaner separation of concerns by allowing aliases to exist in different namespaces.

Implementation Considerations:

1. Syntax Proposal: The syntax could resemble TypeScript's type keyword or use a new keyword like typedef:

   typedef NewTypeName = OriginalTypeName;

2. Static Member Handling: Ensure that static members of the original type are accessible through the alias.
3. Namespace Scoping: Allow aliases to be defined in any namespace, independent of the original type's namespace.
4. Global Scope: Optionally, introduce a global typedef keyword to define aliases that are globally available.

Example:

// Define an alias in a different namespace
namespace BusinessLogic.Models
{
    typedef Result<T> = Api.Models.Response<T>;
}

// Usage
namespace BusinessLogic.Services
{
    public class Service
    {
        public void ProcessResult(Result<int> result)
        {
            Console.WriteLine(result.Message);
        }
    }
}

Alternatives:

1. Continue using using directives, but this requires repeating the alias in every file or using global using.
2. Use inheritance or interfaces, but this introduces unnecessary complexity for simple aliasing scenarios, and it doesn't support up-convert.

In discussion #1300 , someone has told about this issue, but it looks that his usage is not so specific.

[timcassell]

I think this will be covered by roles. #5496

[RikkiGibson]

re: Conceptual Separation, check out https://github.com/SteveDunn/Vogen. Looks like a solution that is gaining some broader interest.

global using (introduced in C# 10, but it doesn't support generic type)

Why don't we fix that?

[fitdev]

re: Conceptual Separation, check out https://github.com/SteveDunn/Vogen. Looks like a solution that is gaining some broader interest.

It would be much better if C# was able to enforce it at the language level. Enums are kind of like this in a sense that they are really just integers but with a strong type identity. So it would be great if we can have readonly struct Count : uint { ... } for example.