Preview Feedback: C# 12 Alias any type

[KathleenDollard]

Aliases for any type (except nullable reference types) are included starting in C# 12 preview 3.

You can use this discussion for feedback as you use the feature.

You can learn more about aliases for any type in the article What's new in C# 12 article.

[fforjan]

Brainstorming here, I didn't have time to try but looking for feedback. We have an issue where our applications is case insensitive, meaning when we compare names, we cannot use the == operator. We have done a roslyn analyzer rule which check for the Name property of a specific interface. Any other property is not checked.
Could we use alias in that case like using OurObjectIdentifierType = string; and then update our roslyn analyzer rule to check for the == usage on a OurObjectIdentifierType type on any property ?
In order word, what is the integration with rolsyn analyzer ?

[333fred]

Roslyn analyzers have access to the full symbol model, including seeing things like IAliasSymbols. Nothing about this feature affects what they can see or would affect your using aliases for that scenario. A better place to have this conversation is probably on https://discord.gg/csharp, in the roslyn channel, where you can talk to multiple developers on the roslyn project about how you might accomplish this.

[fforjan]

Thanks for the info! I didn't dknow about the discord !

[BartoszChrostowski]

Porposal suggests the change:

The order in which using_alias_directives are written has no significance, and resolution of the (namespace_name | type) referenced by a using_alias_directive is not affected by the using_alias_directive itself or by other using_directives in the immediately containing compilation unit or namespace body. In other words, the (namespace_name | type) of a using_alias_directive is resolved as if the immediately containing compilation unit or namespace body had no using_directives. A using_alias_directive may however be affected by extern_alias_directives in the immediately containing compilation unit or namespace body.

which highly limits the use case for such an aliasing system to the readability within one compilation unit. However, if we were to take two separate compilation units, it seems like it would make it harder to understand. Force developers to read using directives to understand why we can put ("m", 100) in place of Measurement (as in example using Measurement = (string Units, int Distance))

Are there any plans to further extend the types system? It would be reasonable to allow such aliasing that would allow type naming to propagate outside the compilation unit. It would allow users to define such things as already for example string = System.String is themselves globally and would solve the problem I have described above.

[CyrusNajmabadi]

Porposal suggests the change:

This has been the logic for using aliases since their inception. The proposal doesn't change anything wrt to that.

It would be reasonable to allow such aliasing that would allow type naming to propagate outside the compilation unit.

You can allow aliases to propagate outside a compilation unit by making them global :)

[BartoszChrostowski]

What I am trying to say is that I am afraid that the fact it does not propagate may lead to some serious mess.
Given two compilation units:

using Measurement = (string Units, int Distance)
public int Foo(Measurement measurement) => Boo(measurement);

using Distance = (string DistanceUnit, int Distance)
public int Boo(Distance distance)

You will have to understand what Measurement and Distance are.

What differs between aliases for namespaces and types is that in the case of namespaces, the feature allows using types with the same name from different namespaces in a readable way. The name of the type does not change. You can more or less guess what's the underlying type (the only mistake you can make is guessing the wrong namespace). In the case of type aliases, you can do stuff that may make it impossible.

[omariom]

You can allow aliases to propagate outside a compilation unit by making them global

What!? 😮
How did I miss that?

[BartoszChrostowski]

C#10 what's new article, global usings

[JiriZidek]

Do I understand well that this is still a syntactic suger with no impact on assembly DLL ? So there is no need for public/private logic, since after compilation there are no "type aliases" like Measurement ??

[CyrusNajmabadi]

This is exactly the same as current aliases, just that what you can alias has been expanded to any type, not just named-types.

[keithn]

Problem with an alias is it isn't a strong type, so from https://devblogs.microsoft.com/dotnet/check-out-csharp-12-preview/?WT.mc_id=DOP-MVP-5001655 where they show ... using DatabaseInt = int?;

DatabaseInt isn't protected such that you couldn't assign it QueueInt.

[CyrusNajmabadi]

And
using CostAPISignature = System.Func<Player, FixedPoint, LoadedActionConfig, bool>;

Delegates are nominal types. This would force people away from structural typing for Func/Action, which would push us backwards against the very thing we worked towards 15+ years ago due to all the problems around nominal typing here.

This is the benefit of aliases. They can give you good names, without going into the nominal typing space.

[CyrusNajmabadi]

Should be record struct

Why? Now you have another nominal type that is incompatible with simple tuples. Not every time one want a good name does that mean they want a full type :)

Aliases exist precisely because, since C# 2, there has long been a space for just names, without new types. Nothing in that regard changes here. Just a simple relaxation around restrictions that really didn't have any particular justification behind them, and whcih teh community gave lots of feedback on over hte years that htey wanted removed.

[tannergooding]

Now you have another nominal type that is incompatible with simple tuples

This is also undesirable when you're simply trying to use a tuple to improve some internal implementation details and where a full type is just too much.

Not everything is public surface area and not everything needs to have the full surface implemented.

[CyrusNajmabadi]

@tannergooding agreed.

[BartoszChrostowski]

Delegates are nominal types[...]

My bad. The delegate part was stupid. I'm sorry.

Not every time one wants a good name does that mean they want a full type

It is hard for me to imagine an example in which I would prefer tuple. Can you provide some example?

Aliases exist precisely because, since C# 2[...]

I mean, that is a good argument in favour of this feature that this is just a relaxation. I am probably not fond of those aliases overall 😄

Thank you for your explanations and discussion.

[olivermue]

I'm also seeing, that this feature will be highly misused or misinterpret by most casual programmers. Instead of a simple alias that could lead to misinterpretation, I would favor real derived types (maybe with constraints) like in F#. By that way we could create types like ValidatedString that will be created by functions like ValidatedString Validate(string maybeEvilMessage) and ensure all business logic methods only consume a ValidatedString instead of string.

By creating the alias type feature people are going to create exactly this kind of code and feeling safe, but it will be only an alias and still allows to call Process(ValidatedString message) with a simple string leading to undesired behaviour. So please really consider to drop this feature. What would really help would be to create easily alias types like public class ValidatedString : string to use the type system also on a business layer to differenciate between the different usages of string, int, Guid, etc.

[CosminSontu]

The question is... Will there be another language feature / concept that will address these points?

Def open a discussion of you're interested in that :-)

The language team should be interested in that, don't you think?

And the language team is really listening :)
I was watching Microsoft Build 2023 : What’s new in C# 12 and beyond | BRK203H presentation on yt (https://youtu.be/hq6uEaMYf5U?t=2366) and at minute 39 Mads and Dustin showcase this code sample:

public explicit extension JsonString for string 
{
       public DataObject Parse() { ... parse as Json ... }
}

void Display(JsonString json) { ... json.Parse() ... }

Display("""{ "customer" : { "name" : "Microsoft" ... } }""");

This is pretty much what I was describing when I said "letting extension methods do their thing". This is the right approach since it does not add complexity. The "for" there is akin to how Rust impl blocks are defined. I think this is great!

[JiriZidek]

But without typedefs allowing things like "Tee" | "Cofee", or ranges (0...100) it is just half of the problem. These "types" should have overridable static methods (aka convertors from their primitive parent) to do gate guard of values into the "type" (by throwing OutOfRange).

[Richiban]

@HaloFour

Looking back on it now, I kind of wish the team hadn't implemented records as a language feature; I would much rather they had implemented primary constructors (as they are currently, in preview) and then some out-of-the-box source generators for equality, public properties etc (and maybe a Record super generator that combined them all). That would be a much more flexible and extensible state to be in now, I feel.

[HaloFour]

@Richiban

Possibly. I brought that up and members of the team felt that the use cases were compelling enough to deserve their own first-class language feature. But the fact that records are a language feature doesn't preclude using source generators to design your own that behave as you would expect. Although you couldn't use with as that feature is still tightly tied to records and hasn't yet been decomposed into a separate feature.

[CyrusNajmabadi]

That would be a much more flexible and extensible state to be in now, I feel.

That is still possible today. Almost every part of a record is something the user can customize. So you can def still use generators for your flexibility/extensibility use cases. This was def something we considered and felt was a good way to handle this situation.

[JiriZidek]

I only sorry that the keyword is not "type" like in majority of languages.

[CyrusNajmabadi]

This is the syntax C# has had since C# 2.0 (Back in 2005). :)

[HaloFour]

@CyrusNajmabadi

This is the syntax C# has had since C# 2.0 (Back in 2005). :)

It's been in the language since the beginning, it's in the ECMA-334 1st edition (December 2001), 16.3.1 Using alias directives.

[CyrusNajmabadi]

Ah, you're right. I was thinking of another feature we did in 2.0 (namespace aliases ::, and got the timelines confused).

[JiriZidek]

Which keyword do you mean?

"using"

But by further reading I realized, that the feature is probably not about defining new "types" (like in Turbo Pascal or TypeScript), but rather just macro definition. If that is the case, I'd reconsider this, and "using" looks appropriate.

[CosminSontu]

Which keyword do you mean?

"using"

But by further reading I realized, that the feature is probably not about defining new "types" (like in Turbo Pascal or TypeScript), but rather just macro definition. If that is the case, I'd reconsider this, and "using" looks appropriate.

Indeed, a typedef would be needed, specially for library authoring. Global usings have to be placed in all client projects of the library to work as intended.
A typedef would create an alias type and this alias would be imported with the library... Also, you could define behavour against the alias and the behaviour would be applicable only to the alias.
This could be a nice entrypoint for union types...
typedef EmailAddress = String
typedef OptionalPerson = Person | Nobody

just dreaming...

[AlwaysHC]

Instead of just "alias" I'd like to see type checking.

[huoyaoyuan]

Please note that this is NOT a brand new language feature. It just fills the gap for the already existing feature since C# 2.
Aliasing to create separated types was discussed for a long time, and is likely to be covered by roles/extensions.

[keithn]

sure.... I'm not sure you are breaking out of your bubble enough to see the problem though. It is already being promoted, by microsoft, as way to create pseudo types, the examples given are what should really be typedefs, they are the examples given, you are enabling a mess. But you guys only see "This is just a feature we already have and we are opening it up a bit more" .... opening it up a bit more to create a mess of types that aren't types. I get it, you don't want to listen to that and think it's all fine, but the very article, by microsoft, promoting pseduo/messy types is the one tell us to come here to provide feedback. If you just want to defend the feature against the feedback, that's your choice, but I think its clear from the feedback that really you should do something different to get typedefs before you do this so we don't end up with a mess. Telling us you discussed it a long time ago and done nothing about it just makes it worse :) You do see that opening it up lets people, because it is the only way to do it, create types from things like primitives that aren't type checked? You do see that is how it is being promoted already?

[CyrusNajmabadi]

he feedback that really you should do something different to get typedefs before you do this so we don't end up with a mess.

Aliases already exist and shipped. This happened back in C# 1.0. This language change is just simplifying a restriction the language had that wasn't really necessary. It's no more and no less than that :)

Telling us you discussed it a long time ago and done nothing about it just makes it worse

We haven't done 'nothing' about it. THere is full scale work going on in this space right now both in design and in terms of prototype implementations. I'm not sure how you got that idea that because we did a little simplication here that we're not working on features like the ones you're asking for :)

You do see that opening it up lets people, because it is the only way to do it, create types from things like primitives that aren't type checked?

This was always possible in C#. You could always create non-checked type aliases to primitive types. You could do that in C# 1.0. Nothing about this relaxation changes that. :)

[En3Tho]

It's clear from your feedback that you want entirely different feature without any spec attached.

How do those strict aliases work? How do they interoperate with base type, with each other? How do they work with instance methods of base type, how do they work with static methods that take base type? How do you cast base type to this new one? How do you validate it is actually a correct value?

There are lots of questions and they should belong to a different discussion altogether because it's a totally different feature that resembles roles (a new feature) and has nothing to do with C#'s aliases. Calling it typedefs or any other term from another language doesn't make sense because it is not that.

[Bellarmine-Head]

From this distance, I can't see myself using the alias any type feature that much (could be wrong; you never know!), but I'm very grateful to this discussion for putting me on to the newtype form:-

public readonly record struct AuthToken(String Token);

That's something that I've wanted in C# for a long time, but I had thus far overlooked this feature of C# 10.

[HaufenKlaus]

Wouldn't a private struct record be the same as an alias? I don't get it, C# Language features were about having to write less, now it is about writing things differently. I'm still waiting to for actually useful semi-auto properties that have been promised since C# 10 (?) How about you stop botching easy to implement bloatware on top and do the work that is actually useful... You were a bit slow before C# 8 when it comes to implementing features, now you can't differ quantity from quality....

[CyrusNajmabadi]

Wouldn't a private struct record be the same as an alias?

No. That would be a type with a different name. An alias is fully erased. It isn't anything new. It's jsut a name you can use in code as a simpler/different way to refer to a type or namespace (but is still that type or namespace).

Wouldn't a private struct record be the same as an alias?

Aliases let you write less.

now it is about writing things differently.

Aliases have existed since C# 1.0. This was just relaxing a rule we had in the language that the RHS had certain annoying limits on it (limits that became more annoying as the language has added more and more types).

I'm still waiting to for actually useful semi-auto properties that has been promised since C# 10

That is still be working on.

and do the stuff that is actually useful...

This feature was one of hte most requested and highest voted ones in all the language. What may not be useful to you is still useful to the rest of the community. And, as i mentioned, we continue to work on 'semi auto properties'. I'm the author of that specification and it's something i can say we've been working hard on.

[HaufenKlaus]

OK, I look into that, thanks for that info ;-)

[CyrusNajmabadi]

You're welcome :)

[vladimir-kovalyuk]

I'm looking for the feature that would help addressing the Primitive Obsession problem. There are a lot of expositions of this problem in different areas. For instance in terms of identity of the objects we used to identify them via Guid or integral type. The method that accepts identities of multiple different entities opens the possibility for the errors where entities are mixed, for instance:

void Foo(Guid departmentId, Guid employeeId);
Foo(employee.Id, department.Id);

Or units of measurement suffer with the same problem:

double miles = 100;
double kilometers = 10;
miles += kilometers;

Unfortunately aliases do not help with primitive obsession. Shall I create another proposal?

[ufcpp]

#6406
#6681
#7031

[JiriZidek]

F# solves

[carnitron]

I have one request I'd like to throw in related to using aliases for any type. Maybe it's a separate feature, I'm not sure. I haven't and won't have time in the immediate future to put together a super tight spec, so forgive me if I have overlooked something.

Request:
I would like to be able put using statements in any scope, not just at the top of the file. And the aliases would apply to just that scope.

Reasons:

1. I want to make an alias to a nested type in a nested class, but since I have to put it at the top of the file, I have to expose it outside of the parent class, if it's even possible in the situation.

2. I often use nested static classes to fully qualify big banks of constants and similar static functions. Fully qualifying them ensures clarity and prevents naming collisions. But it is a lot to type. I know this is why you added "using static" syntax. But all of those usings are up at the top of the file. So you lose the clarity they bring at the point of usage. If you could put them NEXT to the point of usage, you'd get the best of both worlds: minimal typing AND clarity.

3. When I use the "using static" syntax to minimize what I have to type, it's easy to get into situations where can't tell what constant/function/etc. is backed by an alias and where it came from. Since the fully qualified name is gone, the syntax often makes it look like the thing I am referring to is local to the class and not from somewhere else.

4. Sometimes naming collisions in like namespaces prevent you from being able to remove all of your naming qualifications.

Example:

So this:

public void Thing(double[] numbers)
{
    double average = A.B.C.D.E.F.Metric.Average(numbers);
    double stdDev = A.B.C.D.E.F.Metric.StandardDeviation(numbers);
    // ... Many more metrics.
}

Or this:

// Way at the top of the file.
using static A.B.C.D.E.F.Metric;

// Pages of code later:
public void Thing(double[] numbers)
{
    double average = Average(numbers);
    double stdDev = StandardDeviation(numbers);
}

Would become this:

public void Thing(double[] numbers)
{
    using static A.B.C.D.E.F;

    double average = Metric.Average(numbers);
    double stdDev = Metric.StandardDeviation(numbers);
}

Or even better, this:

public void Thing(double[] numbers)
{
    // Adding the "connecting" definition here makes it completely unambiguous what functions I'm using at the
    // call site.
    using static Metric = A.B.C.D.E.F.Metric;

    double average = Metric.Average(numbers);
    double stdDev = Metric.StandardDeviation(numbers);
}

Hope this all makes sense. Thx for reading.

[CyrusNajmabadi]

Hi @carnitron please open a new discussion on that idea. Thanks!

[carnitron]

Sure!

[carnitron]

Here:
#7238

[carnitron]

FWIW, I like this proposal.

I am constantly waging a war to reduce visual clutter and eliminate complex expressions and overly long lines. People talk about being explicit to increase clarity, but the positives quickly turn into negatives when you start combining tuples, generic types and fully qualified names. Visually parsing the super explicit thing you are looking at becomes hard and sometimes even requires temporary on-the-spot editing to break statements apart to simply read it all, let alone understand what is happening.

I love tuples but don't use them as much as I'd hoped in some cases b/c of this issue. Hopefully this proposal nails that.

I do think a type system would be good too. C# pretty much systematically improves and simplifies nearly everything in C++ and it is almost comical how much easier the language is to use and how much more empowering it is; I probably write C# 2x-5x faster than I write C++ code, with far fewer bugs.

The one area where this hasn't been true for me so far is usings vs typedefs. (Though usings are obviously way better than includes.) I have found myself trying all sorts of things to work around some of the issues here, and ftm have settled on writing generic classes to have little subclass wrappers for different type combinations to give them simpler names.

It sounds like you guys are working on something long term there, which would be awesome.

Personally, I love that the C# team continually makes improvements to the language that make me more productive and reduce what I have to write. Complexity is a tricky thing; but I'd rather have the complexity be in learning lots of simple features than entangled in a large codebase that would be simplified by those new features. Less is more for MY code, not the language feature set (within reason, ofc).

So keep it up. It is absolutely understandable that some of the features the community wants are complicated and have to be thought through and implemented carefully, perhaps over multiple versions. And in the mean time, it is still good to deliver value via easier, simpler features.

Cheers.

[Shadowblitz16]

Can we get a way to alias types inside namespaces?

I would like to wrap up some types for my game engine instead of having to reference the library or write my own

[AntonGavrilov]

Hello, can we make alias for static methods? So we can add global using for Console methods for example: Console.WriteLine method (global using WriteLine = System.Console.WriteLine;) and after this we can use just WriteLine everywhere insted of Console.WriteLine.

[CyrusNajmabadi]

You can do that with global using static System.Console;

[TylerBrinkley]

I know the C# 12 ship has sailed but I was sad to see that this alias any type feature doesn't support generic types. For instance, where I work we have a different notion of what a Task is. I've explored getting us to rename it due to the conflict but it's baked in pretty heavily and is a central part of our system, so we've defined a global using alias for System.Threading.Tasks.Task as SysTask. Unfortunately, we cannot do the same for System.Threading.Tasks.Task<T> for consistency and so we use Task<T> and SysTask throughout our codebase which is a bit unfortunate but not a huge deal.

[CyrusNajmabadi]

@TylerBrinkley that is tracked already with #1239

[TylerBrinkley]

Thank you

[RenderMichael]

Has there been discussion on using static <type keyword> such as using static string? As a minimal strawman:

using static string;

var combined = Join(' ', 1, 2, 3);

Today we have to do using static System.String.

This would be well in line with aspects of C# 12's alias any type such as aliasing tuples instead of having to use ValueTuple directly.

[333fred]

I would champion such a proposal.

[Perksey]

This would be cool. Would it just be keywords, or would anything that could be accepted as an argument to typeof be accepted as well?

[CyrusNajmabadi]

Note: this was not done because the cases where static members arise are basically identical to the cases where named type can be used. So there was no 'gap' per se. saying, for example, using static System.String; works equally as well, with the exact same semantics.

[Hermholtz]

FYI, I wanted to alias the following type:

using ValueReader = System.Func<byte[], ref int, float>;

but it doesn't accept ref (CS1073: unexpected token 'ref'). The following is syntactically okay:

using ValueReader = System.Func<byte[], int, float>;

but for my scenario ref would be helpful.

I also tried out (just to check if it works) and it's also not accepted, albeit with a different error message:

using ValueReader = System.Func<byte[], out int, float>;

CS1960: Invalid variance modifier. Only interface and delegate type parameters can be specified as variant.

Maybe in the future it could be improved to accept ref and out. Thanks.

[HaloFour]

That's not related to aliasing. You can't change the "ref"-ness of a type through generics. You'd need a different generic delegate that explicitly defined the parameter as ref.

[Hermholtz]

So, is it "alias any type" feature, or "alias any type, but"?

[sharpchen]

Func and Action don't support ref, out, params and other modifiers, it's not an issue about type alias

[Hermholtz]

Thank you, that explanation I understand. I wasn't aware about this.

[HaloFour]

You could define a delegate with that specific signature:

public delegate float ValueReader(byte[] arg1, out int arg2);

Then you can use that for lambdas, callbacks, etc.

You could also define it as generic, but you'd have to make the second param ref/out:

public delegate TR OutFunc<T1, T2, TR>(T1 arg1, out T2 arg2);

and then alias that:

using ValueReader = OutFunc<byte[], int, float>;