Type aliases that cannot be assigned to other types than itself or it's basetype.

[thargol1]

proposed syntax

using explicit Studentnumber = string;
using explicit Employeenumber = string;

workings

Using explicit is a compiler only instruction that prohibits assignments to or from those types other than from the type itself or it's base type.

These assignments are ok

Studentnumber a = "123456"; 
var b = (Studentnumber)"123456"
Studentnumber c = "123457";
a = c;
Employeenumber e = "12345";
a = (Studentnumber)e; // <-- not smart, but it will compile
string x = a;
x = e;

These assigments generate a compiler error:

Studentnumber a = "123456";
Employeenumber e = a; // <-- error
Employeenumber f = (Studentnumber)"12345"; <-- error

These function calls generate a compiler error:

Student GetStudent(Studentnumber s)
{
    ...
}

Employeenumber x = "12345";
var s = GetStudent(x) // <-- error

Why

Many key-like types in applications are either string or integral type. Preventing those types from accidentily be assigned to each other could prevent errors during compile time.

I tried solutions like value structs. But they require a lot of extra code to make them work with JSON or EF.

Lowering

This should be a compiler only function.

Studentnumber a = "123456"; 
var b = (Studentnumber)"123456"
Studentnumber c = "123457";
a = c;
Employeenumber e = "12345";
a = (Studentnumber)e;

Lowers to

string a = "123456"; 
string b = "123456"
string c = "123457";
a = c;
string e = "12345";
a = e;

[ufcpp]

#7642

[nyan-cat]

Opaque type aliases in C# is something we want since the last ice age

[FaustVX]

You will be able to do that with the extension proposal :
explicit extension StudentNumber for string {}
explicit extension EmployeeNumber for string {}

[FaustVX]

@HaloFour Yes, it's just that I prefer to have a better distinction between the 2.
At the end, I'll be happy whatever it'll be called, as long as at the final stage they have some validation process included.

[thargol1]

I like the syntax proposed by @HaloFour. It's clean and readable.

Would having an is operator also allow for stuff like this?:

string a = GetInput();
if (a is Email email) Console.WriteLine($"valid {email}");

And would implicit conversion back to string still be possible? I don't like writing custom converters for EF, JSON, XML and other future packages that may come our way.

And would this be a compiler only option? So I can use it in old .Net framework 4.8 projects, where I now can use C#12 without problems.

[CyrusNajmabadi]

I like the syntax proposed by @HaloFour. It's clean and readable.

That is the syntax for extensions :)

And would this be a compiler only option?

Unclear what this means. We're discussing language changes here. No language changes will work unless you get a compiler that supports that language version.

[thargol1]

With a 'compiler only option' I mean new syntax that doesn't require updates to the frameworks like .Net Core 9, but works with any supported version of .Net Core or .Net Framework.

[CyrusNajmabadi]

That's out of scope for hte lang design part of things. Speaking to the team/compiler position: we can and will take advantage of new runtime features, and lang features have no guarantee of working downlevel at all. If they do, great. But you're in completely unsupported territory, and things may break at any moment, without any support.