[Discussion] allow cascading type alias

[leandromoh]

Currently, we can not use an alias inside another.

This does not compiles:

    using CustomerId = System.Int32;
    using CustomerRegistry = ValueTuple<CustomerId, string>; // not work

This should be very usefull because allow more concrete and composable reuse of alias.

For now, we must define as follow (knowing implicitly that int referes to CustomerId)

    using CustomerRegistry = ValueTuple<int, string>;

but if CustomerId type changes (let say from int to Guid, for example), we should update manually each alias that makes implicit reference to it. This also may be confusing if a third alias is also an int.

This would be also very usefull with #3428
Perhaps we could implement it at same time as #1239

[333fred]

Perhaps we could implement it in same time as #1239

I recall this being mentioned during triage for 1239.

[leandromoh]

@333fred since #1239 stands for other feature I did not read it full.
but do you think this feature proposal may be accepted?

[333fred]

but do you think this feature proposal may be accepted?

1239 is championed by a member of the LDM and will be considered for some future version of C#.

[marksmeltzer]

A bit tangential, but combining this with the ability to alias named tuples would be extremely useful.

My preference would be an outcome like this:

    using CustomerId = System.Int32;
    using CustomerRegistry = (CustomerId Id, string Name);

[leandromoh]

this of course would be amazing! especially if we have global aliases. but probably would be other proposal

[marksmeltzer]

I can survive without global aliases in the core language. We already tools for that if needed using things like post-sharp, etc.

[AartBluestoke]

Would some type of first class type sub-types be a better solution?
with your using CustomerRegistry = (CustomerId Id, string Name); you are still relying on convention to avoid people putting AddressId's (also int) into your CustomerId slot.

Once this was in, people would alias all their types, then they'd put an AddressId into a function call requesting a CustomerId and ask 'why did that work without a warning'.
Global alias don't feel like 'the pit of success' solution to this, unless the compiler can defend against using the wrong alias.

[marksmeltzer]

There's pros and cons of functional style programming, which tends to make heavy use of value tuples. Value tuples are also an excellent way to return multiple values from a Task as well. In cases where the API consumer cannot be trusted to use the tuples properly, then replacing the tuples w/ classes or structs is the way to go.

I have been writing a lot of reporting code lately using Deedle, and man the code can get nasty looking with all these tuples flying around with frames, series, etc. I tried cleaning it up a bit by aliasing the ValueTuple instances, but that turned out to be dead in the water once I discovered that there's no way to add aliases for named value tuples.

Moreover, I have resharper setup for my team to force using explicit types when the type is non-obvious. So, code that looks like this:

var result = await someTask;

... gets automatically turned into this awfulness by our Resharper code cleanup rules (not resharper's fault! although I would like them to add a new middle ground configuration option to let named tuples or other long generic types stay as "var"):

(Frame<int, string> InterestingData, string InterestingColumn, Dictionary<string,int> InterestingRows) result = await someTask;

I would much rather alias that tuple using a friendly name so that the code can be easier to read.

[marksmeltzer]

Moreover, I think the @leandromoh's original example of CustomerId = System.Int32 is quite contrived. I'm typically using alias for generic stand ins.

[leandromoh]

@marksmeltzer yep, as a contrived example.
What I have seen a lot in real world application are methods that return something like (T data, bool sucess), what adds a lot of boilerplate, especially because this pattern tends to bubble...

[marksmeltzer]

Agreed. I typically use deconstruction for return values where possible. Most of the bloat I'd like to reduce comes when using tuples with generics. Tuples + generics tends to produce very verbose code.

I can alias those using ValueTuple, but losing the Metadata around the names isn't desirable. I know those are all duck typed. So maybe that's why the alias mechanism doesn't support them.

I believe the compiler currently lets us alias the same type multiple times, since aliases are simple one way transforms. So I don't see what special problem the tuple Metadata might present, if any.

[soroshsabz]

ITNOA

@leandromoh I think the answer of this discussion in #4284 , when I can using aliases for anything, so I can using aliases for another using aliases.

[leandromoh]

Even after the feature Champion: using aliases for any types be implemented.
The following code still does not compile (using dotnet 8) 😢

using System;
using CustomerId = System.Int32;
using CustomerRegistry = (CustomerId, string);

Console.WriteLine("Hello World");

[HaloFour]

C# still does not support referencing another alias within an alias. If you change it to using CustomerRegistry = (System.Int32, string); it will work.

[leandromoh]

is there any prevision to support it? the benefit of using nested aliases is that if you chance the inner alias all other dependent aliases changes automatically.

[HaloFour]

You can open another discussion about supporting aliases in aliases within the same set. As of now it doesn't appear to be a part of any championed language proposal, and the more aggressive aliasing features originally discussed in #4284 ended up getting cut.

[leandromoh]

since the title of the discussion already is about aliases in aliases look appropriated for me to continue here