Proposal: Type equivalence

[vbcodec]

Ideally, every type should be defined once, packed into some library and used where appriopate. But in reality we have github, nuget, shared projects, linked source files and infinite number of libraries, what means that some type may appear more than once in project, and cause problems (errors).

class AAA // in our source
{}
...
void proc (AAA input) {} // in our source
...
AAA x = null; // in our source
...

x = GetResultOfAAAFromLib(); // return AAA from first library - error
proc(GetResultOfAAAFromLib2()); // return AAA from second library - error

Despite that all three AAA types are identical (name and members), they are formally different, and that is cause of errors.

So there is need for type tolerance, and field of one type can accept object of 'compatible' type.
Ability to replacing objects in variables / fields / properties regardless of type is very usefull and increases mutability of data. Using type equivalence greatly reduce need for using interfaces or using pure object type.

[YairHalberstadt]

This would have to be a request for dotnet runtime. Many types are not even written in C#. Also it would be a breaking change.

[svick]

Do you have specific examples where this actually happens? To me, it sounds like a solution to a problem that doesn't happen very often. And when it does happen, it's likely that the two types are going to slightly different, because they diverged from the original source, so this wouldn't work well anyway.

[ufcpp]

Structural typing?

[ufcpp]

If you don't mind unsafe, undocumented, and unsupported abuse, you can use Unsafe.As method:

using System.Runtime.CompilerServices;

namespace OneAssembly
{
    public class A
    {
        public int X;
        public string Y;
        public virtual void M() => System.Console.WriteLine($"OneAssembly.M {X} {Y}");
        public virtual void N() => System.Console.WriteLine($"OneAssembly.N {X} {Y}");
    }
}

namespace AnotherAssembly
{
    /// <summary>
    /// different type from <see cref="OneAssembly.A"/>
    /// but the same field layout and the same virtual table.
    /// </summary>
    public class A
    {
        public int X;
        public string Y;
        public virtual void M() => System.Console.WriteLine($"AnotherAssembly.M {X} {Y}");
        public virtual void N() => System.Console.WriteLine($"AnotherAssembly.N {X} {Y}");
    }
}

class Program
{
    static void Main()
    {
        var one = new OneAssembly.A() { X = 1, Y = "aaa" };

        AnotherAssembly.A trickyOne = Unsafe.As<AnotherAssembly.A>(one);

        trickyOne.M(); // OneAssembly.M 1 aaa
        trickyOne.N(); // OneAssembly.N 1 aaa
    }
}

[HaloFour]

What defines the "type" in this case? Is there an expectation that the language and runtime will compare all of the metadata (and referenced metadata) for all types in all referenced assemblies and try to determine if the types are effectively identical? If that type references another type does it have to do the same exact analysis on that other type as well? Sounds incredibly expensive, and it wouldn't work with any of the reference assemblies as they lack implementation so there's nothing that the compiler can use to actually do that comparison. The reference assembly types wouldn't even be considered compatible with the actual runtime types.

.NET was designed very intentionally so that you can have multiple types loaded with the exact same name from different assemblies and that they will be correctly treated as separate types. You only need to look at Java to see what happens when two types collide in the same package. Classpath Hell is a real thing, and it makes DLL Hell seem like a walk in the park. This is why a lot of Java libs "shade" their dependencies by embedding them and moving them into a separate package, to try to avoid naming collisions. In non-trivial applications it results in multiple incompatible copies of the same class in memory at once.

[ntovas]

This require to heavily modify the language and create a lot of problems, for something that can be solved with a mapper that uses reflection and auto maps properties.

[theunrepentantgeek]

Treating types as the same purely because they coincidentally look the same would critically break the safety of the .Net type system.

It would make adding a new member to a class a breaking change because it would no longer be equivalent to other, unknown, classes.

Your proposal Is saying that, were you dating one of a set of identical triplets, you shouldn’t care which one showed up for any particular date.

I think you should care very much.

[vbcodec]

There is no need to run into negative delusions or unjustified fear

Variables / properties / parameters that can hold many silmilar types will be compiled to object type, together with some runtime check, if incoming type meet some criteria. These criteria will be defined with attributes. There may be restriction from few specified types to most liberal check, where only members of original type must all exist in replacement (incoming) type. To be clear, AAA defined in source is original type, while types returned from library are replacement type.
On language level, there must be relaxed rules for type checking, and compiler should generate metadata that hold information about original type of property / parameter (similar to TupleElementNamesAttribute used to describe names used in tuples).

So, idea is similar to using object type, but without losing type check (and intellisense) at language level.

[Unknown6656]

If you don't mind unsafe, undocumented, and unsupported abuse, you can use Unsafe.As method:

Wow .... typing the domain http://unsafe.as into any browser redirects you to the MSDN documentation..... 😲

[svick]

@Unknown6656 That's because the domain is a 302 redirect to MS docs (née MSDN), registered by @GrabYourPitchforks.

[HaloFour]

@vbcodec

Sounds like you want something like #2290, #110 or #164.