Proposal: Add support for typedef (like in C++)

[aaronfranke]

Currently, in C#, there is no typedef like in C++. My use case for typedef is writing math methods with simultaneous support for float and double (an abstract type, via typedef, would be used in place of either type). Or when creating a descriptive short-hand for types without objects.

Would it be possible to add this functionality to the C# language spec?

[benaadams]

You can do aliasing currently for types based on defines with use using ... = ... with #if to achieve the float/double

#if REAL_IS_DOUBLE
using real = System.Double;
#else
using real = System.Single;
#endif

real Add(real a, real b)
{
    return a + b;
}

Or a native int type (assuming you set #define BIT64 for a 64 bit build)

#if BIT64
using nint = System.Int64;
#else
using nint = System.Int32;
#endif

[stakx]

... and you have to repeat the alias definition in each source file where you want to use the alias.

[DavidArno]

@stakx,

This is no longer true. These days the following is only needed in one source file for the entire assembly:

#if BIT64
global using nint = System.Int64;
#else
global using nint = System.Int32;
#endif

[BinToss]

@DavidArno Since when (which lang version) was this a thing?

EDIT: C# 10 and .NET 6

[miyu]

This doesn't scale to larger multi-project solutions; if you're compiling a program variant and this typedef is returned or ingested in your API, you'd then typically prefer your callers can also use your type alias (e.g. so that they can nint.MaxValue in your example)

[bernd5]

Those type aliases are lowered away completely...

[MkazemAkhgary]

... and you have to repeat the alias definition in each source file where you want to use the alias.

I don't think it would be that hard for compiler to treat it as public, yet its not supported.

[bondsbw]

@MkazemAkhgary using is scoped to the current file, whether it be for importing namespaces, class aliases, or importing static methods.

I would like a global class alias but it would probably be better to use a different keyword.

[aaronfranke]

it would probably be better to use a different keyword.

How about typedef? This would be most familiar to people coming from C++.

[aluanhaddad]

@aaronfranke typedef in C++ has been superseded by the enhanced using alias introduced in C++11 so the familiarity argument doesn't track. If anything using should be enhanced in C#. I also don't see how it is an abstract type. It is just an alias that you can optionally use.

[aaronfranke]

It is useful as an abstract type because you can have situations where a data type can be either A or B, but in-file you just refer to it as type X. A single line can then be changed to make it become A or B.

[aluanhaddad]

@aaronfranke

It is useful as an abstract type because you can have situations where a data type can be either A or B, but in-file you just refer to it as type X. A single line can then be changed to make it become A or B.

I don't think this is a great way to factor code. I have no doubt it works well enough, but it is not expressive. A new language feature should enable clearer expression of ideas.

[contextfree]

It seems like it should be possible at least to have assembly-scoped using. "internal using"?

For me the use case would be more about wanting to avoid the syntactic overhead of putting IBlahBlahBlah everywhere, but not wanting to require clients to use a specific wrapper type.

[aluanhaddad]

@contextfree that's an excellent choice of syntax conveying the semantics perfectly. There's also a proposal, #1180, for namespace level method declarations. Such a feature would I think cover that proposal, which I quite like, as well:

internal using static Namespace.Utilities;

namespace Namespace
{
    static class Utilities
    {
        public static void WriteLine(object value) => Console.WriteLine(value);
    }
}

So while I dislike the example use case of this proposal, your suggestion would make it generalizable to much more interesting scenarios.

[Danielku15]

To extend this proposal with a more modern approach than typedefs:

Haxe, a language for cross-compilation to other languages, has a concept called [abstract types] (https://haxe.org/manual/types-abstract.html) beside the typedefs .

It allows you to define a type which is evaluated to its underlying type during compile time. For this type you can define custom operators, methods. If an abstract type cannot have additional members as the storage will be the defined underlying type, but it can have methods, properties and operators. Haxe also supports inlining of methods which might any overhead. If you do not inline the methods, there will be a class holding the methods as statics. This way you could even implement a "int" that can only hold even numbers.

I personally do not like the fact that they call them "abstract types" as abstract means something else in C# and Java. But by using typedef as keyword we could build a even more powerful system than recycling maybe the C++ style typedef approach.

typedef Color : int 
{
    public inline Color(int i) 
    {
        this = i;
    }
    
    public inline Color(Color c)
    {
        this = (int)c;
    }
    
    public inline byte Alpha => (this >> 24) & 0xFF;
    public inline byte Red => (this >> 16) & 0xFF;
    public inline byte Green => (this >> 8) & 0xFF;
    public inline byte Blue => this & 0xFF;
    
    public static inline Color FromArgb(byte a, byte r, byte g, byte b)
    {
        return new Color((a << 24) | (r << 16) | (g << 8) | b);
    }
    
    public static inline implicit operator int(Color c) 
    {
        return c;
    }
    
    public static inline implicit operator Color(int i) 
    {
        return new Color(i);
    }
}

typedef GameNumber 
#if BIT64
        : double
#else 
        : float
#endif
{
    public void DoSomething(GameEngine engine)
    {
        engine.PutToPool(this); // GameEngine.PutToPool(float f) or GameEngine.PutToPool(double d)
    }
    public static inline explicit operator long(Real c); // auto-operator via underlying type
    public static inline implicit operator Real(long i); // auto-operator via underlying type
}

There would be definitly some details to clarify like:

• Auto exposing of underlying type methods
• Inlining strategy (not sure if the C# compiler already can do that well)
• Exposing of typedefs outside assemblies
• Refection/Dynamic support

This would also allow a bit more strict typing within your library.

[CyrusNajmabadi]

I'm not sure what that buys you on top of what you can already do today (just wrapping your value in a struct that has whatever API you want to expose).

[Danielku15]

The benefit in this case is that on compile time the type is reduced to the underlying type. This means it can also be a class or interface that you wrap in this case. When you wrap it into a struct you will have a lot of wrapping/unwrapping ongoing. Plus: You will have a new type in your assembly and public interface even though you just wanted to have a wrapper with some more meaning. My proposal is more an extension of a typedef too maybe allow more logic. Also a simple typedef could be rebuild with a struct/class + implicit cast operators but in the end that's not the goal.

I saw especially in cross-platform compilation cases such types can be really useful especially if you have platform specific implementations.

The bullet point with "exposing outside assemblies" is maybe misleading. By this I did not mean directly that the typedef is exposed and embedded in the assembly, but rather if you have typedefs in your contract, you might need to consider that the conversion operator of the passed value is invoked at the beginning of the method. If you have a EvenInt type that ensures only even numbers, and somebody passes an odd integer to your method it might need to call your conversion function. Also the bullet point on reflection and dynamic might just end in the decision that typedefs will provide the functionality of the underlying type and additional members are lost.

[jnm2]

This means it can also be a class or interface that you wrap in this case

I missed your point the first few times I read this line. Meaning, you want to be able to pass your typedef type to things expecting ISomeInterface or SomeBaseClass?

[Danielku15]

Meaning, you want to be able to pass your typedef type to things expecting ISomeInterface or SomeBaseClass

Yes, you can basically wrap anything in the typedef, a class, interface, enum or struct (by this also standard data types like string). Just like in C++ the typedef becomes an alias for the original type.

The simple version of a typedef could be typedef MyFloat : float; In this case it is a simple alias. Variables of MyFloat can get float values assigned or be used anywhere where a float is needed. Also it provides all methods/properties etc. forwarded to the original type. A classical typedef or name-alias.

The extended version brings a bit more strict typing into the game. At compile time the alias also gets replaced with the underlying type. But additionally you can define specific operators, methods and maybe properties. The code of those might either be inlined for performance reasons or be placed in a static class with extension methods. It covers the use case that the typedef is more than a simple alias for convenience but really a entity in your assembly it has some more semantics and should follow some rules.

[dozer75]

typedef or extending using could be nice with tuples too to reduce code when using tuples:

typedef MyTuple (int Id, string Name, DateTime Created) or using MyTuple = (int Id, string Name, DateTime Created)

Could result in more readable code (example simplified):

private MyTuple GetInfo(int id)
{
    return something.Select(item => (item.Id, item.Name, item.Created)).FirstOrDefault();
}

private void PrintTuple(MyTuple info)
{
    console.WriteLine(info.Id);
    console.WriteLine(info.Name);
    console.WriteLine(info.Created);
}

Of course you can create a class or struct, but that's more code and in some circumstances (like in internal code) it seems more reasonable to simplify it using a tuple instead of a class or struct.

[aaronfranke]

Here's another thought: However this feature is implemented, it doesn't really need to be global, as long as it allows spanning many files. Perhaps a namespace-level using directive which includes that using statement for all code in the same namespace, and maybe all files including that namespace?

This would be a more generic approach and could also allow things like using static to exist everywhere in the namespace.

[Ozzard]

I have two use cases for this, both heavily performance-related:

• I have a simulation application that represents money, where the same codebase sometimes needs decimal for full precision, sometimes double for higher speed and damn the inaccuracies. "using Money=double" doesn't scale across high tens of files.
• https://github.com/PaulBrack/Yamato where we're doing huge amounts of storage and calculation on mass spectrometry files - it's not unusual for the calculations on a large file to need a couple of hundred gigabytes of working memory. Again, doubles for precision, or floats for reducing the storage requirement and being "mostly right", which is very useful in some cases.

Both of these could be mostly solved by allowing generics to take a restriction of "where T: Number" or similar (list the operations that must be supported, perhaps). Unfortunately this restriction is very difficult to enforce on the primitive types, as for complex reasons they're not first-class citizens in the type space.

[CyrusNajmabadi]

@Ozzard

struct Money { private readonly double _value; } ?

It allows you to ensure you're not innappropriately mixing incorrect types. And, nicely, the runtime will effectively elide everything and you should have full double-perf.

[Trayani]

@CyrusNajmabadi ,
Out of sheer curiosity (and uncertainty), does it mean that the struct is treated as double without the indirection once it gets compiled? If so, it is pretty cool. How is this optimization called? I would like to read more on it.
(sorry for the off-topic)

[CyrusNajmabadi]

Out of sheer curiosity (and uncertainty), does it mean that the struct is treated as double without the indirection once it gets compiled?

Effectively yes. It will still be in the metadata signatures as Money, but that's a good thing.

How is this optimization called?

It's just good inlining. The runtime will see that all your members are very simple, and this struct is just a simple wrapper around double. So effectively all jitting will elide everything unnecessary.

[ericwj]

Much of this can be done with some #define lines added to files copied from some primary file that you edit by hand. Like @Ozzard's use cases. If you don't write decimal or double but number with at the top of the file something like:

#if USE_DECIMAL
using number = System.Decimal; // use as decimal
#elif USE_DOUBLE
using number = System.Double; // use as double
#else
using number = System.Single; // use as float
#endif

So you will see the default in code files as float since there are no defines in the file.

Then you can generate a new file which contains e.g. #define USE_DECIMAL and after that a copy of the file you were editing.

There is a new feature in the newest C# in preview with which this can be made much cleaner than what it gets to look like as described here, but even without code generation this can pretty easily be done with pre-build events (copy a.cs + b.cs c.cs) or in MSBuild or even in a separate project as a custom build step.

[aaronfranke]

@ericwj The problem right now is that this definition has to be repeated in every file. There should be a project-level feature to include such kinds of definitions for usage in every file without having to copy it into each file and without setting up complicated build events (and if I'm understanding this, "number" would not show up as a valid type with intellisense if adding it was a pre-build event).

[HaloFour]

This has been championed, which means that the team will at least discuss it: #3428

[ericwj]

It will work with IntelliSense regardless of how you produce the file. It will just be plain C# that is part of the normal compilation.

This might be useful for some people because

• you don't need to sit on your hands while the Gods ('at'MadsTorgersen e.a.) might or might not favor this.
• having this baked in typedef will give worlds of hurt with C++-like project configuration hell and lots of build configurations which .NET developers usually have the luxury of ignoring completely
• as opposed to typedef like in C++ this in fact allows the variants produced as described to live in the same project and be used in different places at the same time without recompiling

[osamakawish]

Regarding the issue that it has to be repeated in every file, can this not be allowed to be included in the namespace directly? To avoid the repetition?

[keithn]

I'd like a syntax similar to F#s way of defining types type X = Y, I think it should also cover discriminated unions also, though that seems to be trying to use enum, as per #113 Semantic types are a real pain in the ass for C# when they simply have an equivalence with a primitive type.

[badcel]

My usecase is wrapping a C library which uses typedef in its own code to rename primitive value types. To keep the type as expressive as in C and not fall back to the primitive type if writing the pinvoke call it would be nice to have a typedef in C# which is like a global alias for a given type avoiding wrapping it into a struct. Thus matching the C API as close as possible.

[bernd5]

You can write in a single file, e.g. "Usings.cs":

global using Foo = System.Int32;

Then you can use it:

Foo x = 12;

[badcel]

It looks like the global using is not accessible outside of my library? If I’m wrapping a C library to make it available in the C# world users of my library would still see int instead of Foo.

[andre-ss6]

I'd like to have this and have the "typedef" exported. My use case: export "default" generic type instantiation without inheritance:

export using Foo = Foo<Default>;

public struct Foo<T>
{
}

I have used this kind of pattern many times for different reasons (making API consumption simpler for the typical use case being the most common, but also for creating testable code with DI through generics). However, today was the first time I wanted to use this for a struct, and I can't use inheritance there.

[svew]

I keep wishing for a thing like this, it would make my Rest API requests much easier to write with strict typing:

interface IRequest
{
    typedef Response;
}

record MyRequest
{
    using Response = MyResponse
}

record MyResponse
{
}

Task<T.Response> Send<T>(T request)
    where T : IRequest
{
    HttpResponseMessage responseMsg = // send the request...
    return JsonConvert.DeserializeObject<TRequest.Response>(await responseMsg.Content.ReadAsStringAsync());
}

// Call it like this:
MyResponse response = await Send(new MyRequest());

I can do to this without "typedef" right now using abstract classes, but once you start making combinations of different request content serializations (json, binary, no body) and response serializations (json, binary, no body), things start getting very messy...

[tannergooding]

As was covered above, global using alias = Type; works and makes it accessible to every file in the project.

You can even define these at the msbuild (csproj/props/targets) level, which means that you can include it in a NuGet package or similar.

There is nothing blocking or lacking here and I doubt the language will do anything to make it even "simpler", such as embedding such metadata in an assembly. The existing tools are more than sufficient for the niche edge cases you need it.

[svew]

@tannergooding I don't believe global aliasing addresses what I'm talking about. I'm looking for is the ability to add types as members of classes/structs, in order to associate an otherwise unrelated type to it. C++ uses that to allow users to create type overrides for things such as allocators. I'm looking for something far simpler, but still similar, in the ability to define types (e.g. Response) as members of classes/structs (e.g. using Response = MyResponse) so that I can create a clear type relationship between an HTTP request's JSON body and the expected JSON response.

I don't believe there's a way to do this right now, except for creating a subclass of a generic superclass, but as mentioned doing that sort of thing when there's many types to define gets messy

[svew]

I found a more relevant thread for my interest: #8712

[tannergooding]

Associated types would be a different feature with its own discussion thread.

This discussion thread was for what is effectively typedefs, which has always existing in the language (per file at least) via aliases and has had the ability to define per project for several releases at this point.

[aaronfranke]

The new global using feature resolves this, so I'll close this discussion.

[jzabroski]

Yes, but it would also be nice if it could actually define new types rather an alias to an existing identity. That should be a new discussion thread.

[tannergooding]

Defining new strong types can effectively be accomplished with records and a couple helper operators. Source generators are a viable option as well.

Anything further would require its own discussion thread, which I'm sure may already exist.