Discussion: internal aliases

[alrz]

Ported from dotnet/roslyn#7451.

While using-alias-directive "introduces an identifier that serves as an alias for a namespace or type within the immediately enclosing compilation unit or namespace body", internal aliases can be referenced anywhere within a program.

internal using StringMap = Dictionary<string , string>;

• Internal aliases will be erased during compile-time and will be replaced with the underlying type.
• Internal aliases are totally equivalent to the underlying type but, for example, IntelliSense could be extended to suggest only extension methods on the specific type alias.
• Internal aliases (along with file-scoped aliases) could also support generics (Proposal: Support generics and generic type parameters in aliases #90),

internal using Map<T> = Dictionary<string , T>;

Alternatively we could use alias or type, since internal carries some implications:

• InternalsVisibleTo should work with internal aliases but it won't.
• internal is "the default" modifier in a global or namespace context.

However, with CLR support we could extend the set of allowed modifiers for a type alias in the future.

EDIT: Following using static perhaps using internal is a better choice here.

[HaloFour]

So just to be clear, I could add a source file with the following contents:

namespace Foo {
    internal using Map<T> = System.Collections.Generic.Dictionary<string, T>;
}

And have some other source file with the following contents:

using Foo;

namespace Bar {
    static class Program {
        static void Main() {
            var map = new Map<int>();
            if (map is Dictionary<string, int>) Console.WriteLine("yay!");
        }
    }
}

And the compiler will resolve the Foo.Map<T> alias "pseudotype" to the actual type System.Collections.Generic.Dictionary<string, T>?

Also note that I used the fully-qualified type name to define the "alias" Map<T> as currently that is a requirement. You don't appear to be proposing to change that.

[Shadowblitz16]

wouldn't it technically be public using?
internal is scoped to the assembly only.
What if I want to type alias something from what my library is built on?

[jnm2]

Whatever we do here, I hope we don't block a future CLR improvement where I can declare a runtime type alias, enabling me to change the name of a type without breaking source or binary compatibility.

[alrz]

@HaloFour

Also note that I used the fully-qualified type name to define the "alias" Map as currently that is a requirement. You don't appear to be proposing to change that.

Here's the context.

using System.Collections.Generic;
namespace Foo {
    internal using Map<T> = Dictionary<string, T>;
}

To make that work in the same level, RHS should consider preceding using directives,

using System.Collections.Generic;
internal using Map<T> = Dictionary<string, T>;

Which might be a breaking change (not if we only do that for internal aliases).

[alrz]

@jnm2

Whatever we do here, I hope we don't block a future CLR improvement where I can declare a runtime type alias, enabling me to change the name of a type without breaking source or binary compatibility.

Once CLR support this, we can extend the set of allowed modifiers to public and you'd get that in result.

[HaloFour]

@alrz

IIRC, currently the compiler requires fully-qualified type names in aliases in order to avoid potential circular references. How would you propose avoiding that issue with "internal aliases"?

[alrz]

@HaloFour

Could you give an example? Supposedly the compiler can detect such cases as it does for base classes.

[gulshan]

I think rather than redefining what using does, a new typealias or typedef or simply type should be use for this aliasing. And the full qualified name should not be required. And then this should have option to be public, usable from outside of the assembly.

[temporaryfile]

Whatever we do here, I hope we don't block a future CLR improvement where I can declare a runtime type alias, enabling me to change the name of a type without breaking source or binary compatibility.

Type Forwarding in the Common Language Runtime

[jnm2]

@playsomethingsaxman That allows moving a type between assemblies, which I have done, but there is no facility to typeforward a name change or namespace change.

[scottdorman]

EDIT: Following using static perhaps using internal is a better choice here.

Wouldn't using alias actually be better? It's clearer that you're creating a type alias and doesn't carry forward the other implications that internal has (as you already pointed out).

[gulshan]

I think type parameters and user defined access modifiers look better with explicit aliasing syntax using some new keyword like typealias-

public typealias StringKeyDictionary<T> = Dictionary<string, T>;

And using can remain scoped to files. If we prefer to introduce a keyword which can be used for other types of type definition, typedef of just type can be used, as I have already suggested.

[daiplusplus]

I'd like this to have an additional strict modifier that declares a type-alias as having the same binary/object representation as the underlying type but that it represents an incompatible value as far as business-rules are concerned - for example, this would help prevent mixing identity-types in database systems (which tend to all be Int32) without needing to define multiple new struct types, for example:

using strict CustomerId = Int32;
using strict OrderId    = Int32;

#region ORM/scaffold-generated code for business entities:

class Order {
    public OrderId Id { get; set; }
    // ...
}

class Customer {
    public CustomerId Id { get; set; }
}

class Orm {
    public Order GetOrder(OrderId id) { ... }
    public Customer GetCustomer(CustomerId id) { ... }
}

#endregion

My proposed strict aliases are assignable to and from their underlying types without any problems, this is useful when passing values to other methods without casting, or when initializing values from a literal or other source:

OrderId orderId = 123; // ok to assign from Int32 literal
OrderId orderId = sqlDataReader.GetInt32(0); // ok to assign from Int32 return value

Dictionary<Int32,Order> ordersById = ...
Order order = ordersById[ orderId ]; // ok to use as Int32 argument value

Similarly:

Customer customer = orm.GetCustomer( 123 );
Order order       = orm.GetOrder( orderId: 456 );

While this code would cause a compile error:

customer.Id = order.Id; // CustomerId and OrderId are not assignable
Order order = orm.GetOrder( customer.Id ); // `CustomerId` values cannot be used as arguments for `OrderId` parameters.

This example of a database system is contrived and certainly a case where this isn't really a problem in practice, but it would be useful for zero-cost dimensional analysis.

using strict definitions could also be used to restrict extension methods, consider:

using strict Rectangle<T> = Tuple<T,T>;

public static T GetArea<T>(this Rectangle<T> rect) where T : INumber {
    return rect.Item1 * rect.Item2;
}

public static Single GetAreaInCentimetres(this Rectangle<Metre> rect) {
    return ( rect.Item1 * 100 ) * ( rect.Item2 * 100 );
}

Which could then be used like so for zero-cost dimensional unit constraints:

using strict Metre = Single;
using strict Centimetre = Single;
using strict MetricRectangle = Rectangle<Metre>;
using strict Inch = Single;
using strict USCustomaryRectangle = Rectangle<Inch>;

So this works:

Rectangle<Metre> metricRect = new MetricRectangle( 0.5, 2.0 );
Metre metricArea = metricRect.GetArea();

But this won't:

Tuple<Single,Single> weakRect = new Tuple<Single,Single>( 0.5, 2.0 );
Single weakArea = weakRect.GetArea();

Neither will this:

USCustomaryRectangle inchesRect = new USCustomaryRectangle( 19.685, 78.7402 );
Centimetre cm = inchesRect.GetAreaInCentimetres();

[osdm]

How about allowing this inside generic classes? For example:

public class MyOneToListMap<TKey, TValue>
{
    using TValueList = List<TValue>;
    using TDictionary = Dictionary<TKey, TValueList>;
    private readonly TDictionary dictionary = new TDictionary();
}

P.S. Although in my example you can just make derived classes, I've encountered many cases where derived classes are impossible (for example, you must accept/return externally declared interfaces with many type parameters).

[pongba]

Whatever we do here, I hope we don't block a future CLR improvement where I can declare a runtime type alias, enabling me to change the name of a type without breaking source or binary compatibility.

Agreed, exactly what I need

[john-h-k]

You could emit metadata into the assembly, some sort of attribute which defines the aliases (type, string). Then InternalsVisibleTo could work, right?

[assembly: InternalAlias(typeof(Dictionary<string, string>), "StringMap")] etc

[CyrusNajmabadi]

Any idea if any progress is going to be made on this?

There is currently no champion for this item, so the ldm is not prioritizing this in any way.

It would seem very simple to implement this as just replacing what you wrote with the full type name during compilation.

It's definitely not that simple :-)

[alrz]

Some things to consider in this space:

• generic type aliases
• primitive type aliases (int, tuples, function pointers, etc)
• global namespace aliases

There are already proposals for the first two, but I think this is a better place to invest instead of extending using directive.

For namespaces this would be really impactful for layered applications, e.g. in a web app you may have a domain model, api model and business model all with the same name. Using extern alias for each is even less convinient than repeating using on top of each file which still sounds like a workaround and at the end it's really hard to manage all of those and keep them in sync.

F# already supports this (I think only for types) and it's speced that these won't be accessible from outside of the assembly and that haven't been much of a problem so far.

I suspect one reason for this to not get prioritized is that there's no immediate usecase in roslyn or corefx, but it's an absolute necessity in other kinds of applications.

[gulshan]

So proposals useful for Roslyn or CoreFx are prioritized? Maybe that's natural.

[YairHalberstadt]

@gulshan
Without a customer within Microsoft it's very difficult to thrash out the problem domain, and work out what is actually sufficient to solve the problem. Otherwise you're creating features and hoping that they solve the problems people are having, but not finding out till after they're already released.

[333fred]

I suspect one reason for this to not get prioritized is that there's no immediate usecase in roslyn or corefx, but it's an absolute necessity in other kinds of applications.

I don't think this is true. Rather, I think that internal-only aliases is not the approach we want to take. For example, are these a compile-time only construct? If so, what happens to assemblies with IVT? The only logical answer is that they see the original type, not the alias. And if it's not a compile-time only construct, and somehow encoded in metadata, then it would be sad if you couldn't use these in a public interface. But then we have the question of whether aliases are identity-convertible to their underlying type. You might want that for a simple alias of a complicated generic type, but if you were creating a units library, for example, you might want your miles alias to not be identity-convertible to your kilometers alias. Plus, a metadata encoding would likely want runtime support, particularly for the opaque version. So, I don't think that the problem is not something that we want to solve. Rather, I think that we haven't found a proposal yet that we like, and no one on the ldt has sat down to make one either.

[alrz]

FWIW I think the introduction of DUs would make another use case for global aliases, for instance you may have a generic Result<T, E> and you'd want to define aliases for each kind of error:

type ServiceResult<T> = Result<T, ServiceError>

I think that is how all Rust's result types are defined.

[softlion]

That is exactly what i wanted to do today:

typedef UnitVector3 = Vector3

So my extension methods already knows the vector is normalized.
Like in MathNet, but much better architectured.

I have no workaround except embedding a Vector3 in a new class, as Vector3 is sealed.

[jukkahyv]

This has been my personal favorite feature request for a while. It would increase our team's productivity significantly, and we can't be the only ones. I already explained our case at Build Developer Day, but let me post it there too.

Our system has many, many entities (over 200). It's common that their IDs are passed around as plain integers. There's been many cases where developer mixes IDs of different, similar sounding entities, let's say UserContact and UserConfig. So I got an idea to make strongly typed IDs for entities, to avoid mixing them. It's implemented as struct EntityID<TEntity>, for example EntityID<UserContact>. But writing EntityID<UserContact> everywhere is tedious, so we would like to have a type UserContactID that is compatible with EntityID<UserContact>. Obviously structs cannot be inherited, but even with classes, UserContactID and EntityID<UserContact> would be two different types: I cannot have a method that expects UserContactID and is given EntityID<UserContact> as parameter, even though these types are identical. I could work around this with implicit casts, but it's hacky at best, and doesn't work nearly everywhere (what if I have a collection of UserContactIDs?). Many other languages such as C++ have type aliases which would solve this use case. From what I remember from my C++ days, typedef was exactly what would be needed here. It seems simple, but I understand there are corner cases. Ideally we would want these to be public so that they can be shared between assemblies, but even internal aliases would be a big help.

[gulshan]

@jukkahyv Let me just put a plug for my proposal #3046 here, which could be helpful for your specific case. It purposes to have generic types defined as T.EntityId<T> and then use as UserContact.EntityId (or shorter- define as T.Id<T>, use as UserContact.Id).

[Happypig375]

Plugging an already negatively-reviewed proposal probably isn't a good idea.

Regarding the actual relevance of the proposal, UserContact.Id expands to Id<UserContact> which is not the original type as defined by @jukkahyv (EntityID<UserContact>). If you were to write UserContact.EntityID, then it is just as long as EntityID<UserContact>.

[jukkahyv]

Actually, I forgot to mention one big point. By making it a single name (like UserContactId), it can be autocompleted with intellisense much faster than generic type + parameter. It sounds like a small thing, and it is, until you realize you're doing it 10 or 50 times per day.

[Happypig375]

And here I use F# type inference every day. 😃

[declard]

Imagine C# had aliases allowing this:

public abstract class Base
{
  public abstract alias Inner<T>;
}

public Generic<T> {}
public Impl : Base
{
  public override alias Inner<T> = Generic<T>;
}

Then HKT would become unnecessary as you could be able to emulate them using this technique:

H<T> F<H<>, T>(H<T> h) => h;

becomes

class H
{
  public abstract alias Inner<T>;
}
G.Inner<T> F<G, T>(G.Inner<T> h) where G : H => h;

[softlion]

What is HKT

[Joe4evr]

Higher Kinded Type. See #339 for a more in-depth proposal.

[ChayimFriedman2]

@Jehoel

I greatly agree with your suggestion, but I think it's subject for a different proposal.

I would define internal using (or using internal) as C++'s typedef: type alias - shorten a type name.

For your proposal, I would suggest type T = , as you're creating a new type.

Also, this proposal don't require CLR changes (although can benefit from them) - even public aliases could be exposed as attributes, as already pointed out. But your proposal requires CLR changes, because otherwise the following code will result in wrong:

type MyType = int;

// ...

object o = new MyType(5);
if (o is int)
{
    Console.WriteLine("Oops, they should be different types.");
}

Although now it's crossing my mind that it can be implemented by the compiler by new struct containing the type, and re-exposing all of its public members:

struct MyType
{
    int _Field;
    // All int members
}

This will have overhead, but since the JIT will optimize this away this should be fine.

[CleanCodeX]

What is the progress on this topic?

[alrz]

@CleanCodeX See #3428

[YoshiRulz]

Does there exist a hack or third-party solution for the simplest form of this: a global (per compilation unit) alias for a non-generic type, which only exists at compile-time? I can't find anything that's not hypothetical in this thread, in #7451, or on the web.

[daiplusplus]

@YoshiRulz The only feasible option right now is a Roslyn code-generator that creates an almost-zero-overhead struct with implicit conversion defined to/from types you want it to be compatible with.

Note that Roslyn code-generators can't modify existing code on-disk, they can only add new code in hidden .cs files that exist only in-memory (though they can be saved to your obj folder during debugging). So I guess you'd define a custom Attribute class in your project to declare these "aliases" and have your Roslyn code-generator recognize them and generate the appropriate type at build-time (VS will run Roslyn code-generators at design-time too).

I can't see anything on NuGet that does this right now, but it is fairly straightforward, so I'm surprised no-one's done it already.