IIs<T>, IAm<T>, IHas<T>, etc?

[daiplusplus]

I'd like to see a type like this added to the BCL:

public interface IIs<out T>
    where T : notnull
{
    T Self { get; }
}

It could also be named IAm<T> or IHas<T>, or variations thereof.

TL;DR:

• This interface allows consumers of distinct wrapper types (i.e. wrapper types not inheriting from each other, nor the T type-parameter), which could be struct types or class types, or a mix of both) to still be able to participate in object reference-equality comparisons.
• This interface allows constrained generic methods to accept any implementation of IIs<T>, including structs, without boxing, while still getting the inner T object.
• It makes up for the lack of generic interface corresponding to the static operator implicit conversion operators.
• It facilitates using composed generic value-types (in a true builder-pattern, where each method's return-type itself includes the previous return-type) which is safer and easier to reason about than builders that don't expose builder-state in return-types (looking at you, IQueryable<T>...).

Motivation

I have this interface type defined in all of my personal projects because I find it essential when working with other interface-types and wrapper-types when I want to preserve object-identity - this is especially useful when working with Entity Framework types.

For example, supposing I have an EF entity class Order with an IReadOnlyOrder interface added:

public sealed class Order : IReadOnlyOrder, IIs<Order>
{
    public Int32 OrderId { get; set; } // PK
    public Int32 CustomerId { get; set; } // FK for `Order.Customer`.
    public String Subject { get; set; }
    public String? DeliveryAddress { get; set; }
    
    public Customer? Customer { get; set; }

    private readonly HashSet<LineItem> lineItems = new HashSet<LineItem>();
    public ICollection<LineItem> LineItems { get; } => this.lineItems;

    IReadOnlyCollection<LineItem> IReadOnlyOrder.LineItems { get; } => this.lineItems;

    Order IIs<Order>.Self => this;
}

public interface IReadOnlyOrder
{
    Int32 OrderId { get; }
    String Subject { get; }
    String? DeliveryAddress { get; }

    Customer? Customer { get; set; }

    IReadOnlyCollection<LineItem> LineItems { get; }
}

Now if I add a separate type (either a stateful and immutable class - or a readonly struct) to represent an Order that's loaded with Customer and its LineItem collection, then it would look like this (note how it implements IReadOnlyOrder and simply passes-through to its inner Order reference):

public sealed class LoadedOrder : IReadOnlyOrder, IIs<Order>
{
	private readonly Order                    order;
	private readonly Customer                 customer;
	private readonly ImmutableArray<LineItem> items;

	public LoadedOrder( Order order, Customer customer, IEnumerable<LineItem>items )
	{
		this.order    = order    ?? throw new ArgumentNullException(nameof(order));
		this.customer = customer ?? throw new ArgumentNullException(nameof(customer));
		
		if( !Object.ReferenceEquals( order.Customer, customer ) || customer.CustomerId != order.CustomerId )
		{
			throw new ArgumentException( message: "Order/Customer mismatch.", paramName: nameof(customer));
		}

		if( items is null ) throw new ArgumentNullException(nameof(items));
		this.items = items.ToImmutableArray(); // make a private immutable copy, just-in-case `items` is a mutable in-memory collection.
		
		if( this.items.Any( item => !Object.ReferenceEquals( item.Order, order ) || order.OrderId != item.OrderId ) )
		{
			throw new ArgumentException( message: "Order/LineItem mismatch.", paramName: nameof(items));
		}
	}

	public Order                         Order     => this.order;
	public Customer                      Customer  => this.customer;
	public IReadOnlyCollection<LineItem> LineItems => this.items;

	// Other IReadOnlyOrder members:

	public Int32   OrderId         => this.order.OrderId;
	public String  Subject         => this.order.Subject;
	public String? DeliveryAddress => this.order.DeliveryAddress;

	Order IIs<Order>.Self => this.order;
}

The neat thing is that LoadedOrder becomes a drop-in replacement for Order in most places, and this application of dependent-types/refinement-types instantly solves runtime NREs in EF code that makes naïve assumptions about non-null reference and collection navigation properties.

Also, this is example is much simpler than my actual projects: instead of a single class LoadedOrder I'll actually have 10 or more different Loaded... types just to assert that Order has some other combination of reference-properties and collections loaded into memory - all-in-all, there might be hundreds of these Loaded... types in a project.

Now, for the problem that the IIs<T> interface type solves, consider:

• class LoadedOrder is a distinct type from class Order (and no, subclassing Order such that class LoadedOrder : Order is inappropriate (if not outright incorrect) in this context) because Order is a fully mutable class, while LoadedOrder is an read-only view over a mutable Order instance.
  • _{...so they should not have an "is" relationship expressed through inheritance, which is impossible anyway if you want to use a struct instead of a class as the actual implementation type.}
• Functions and types that (pinky-swear) promise to not to mutate an Order object can use IReadOnlyOrder for their parameter and field types, which exposes no setters.
  • So a caller could specify an Order or a LoadedOrder object as the argument for an IReadOnlyOrder parameter, but this introduces the need for dozens of manually-maintained overloads for each type... no thanks.
    • (Yes, LoadedOrder could also have public static implicit operator Order( LoadedOrder self ) => self.Order; but this means you don't benefit from the safety benefits of the IReadOnlyOrder interface, annoyingly there's also built-in interface to represent the implicit operator, which is kinda amazing considering the utility of a hypothetical IConvertTo<T> interface).
• ...but there's a problem when a function wants to accept a mutable Order reference because it wants to pass it into the DbContext's DbSet<Order> member collection:
  • Entity Framework (and Entity Framework Core too)'s DbContext/DbSet<T> types are built-around using object-identity (i.e. Object.ReferenceEquals) to identify and track in-memory objects - so if you want to work with an Order object with EF then you absolutely need to use the Order parameter type: but instead if you use IReadOnlyOrder as the parameter-type and pass that to DbContext.Entry( readOnlyOrderArg ) then that will compile without errors but will always fail at runtime if the IReadOnlyOrder object is not actually an Order object.
  • But this can be rectified by adding IIs<Order> to class Order (as in class Order : IReadOnlyOrder, IIs<Order> and implemented explicitly (to reduce member pollution) as Order IIs<Order>.Self => this; and in each of the LoadedOrderWith... types as public Order Self => this.Order;)
  • ...then the function can be redefined as a generic method over TOrder, i.e.: DoSomethingWithOrder<TOrder>( TOrder order ) where TOrder : IReadOnlyOrder, IIs<Order> then the single method DoSomethingWithOrder can now accept any IReadOnlyOrder object that exposes its inner Order object (so the Order can be passed directly to the DbContext) without any overloads or custom structs implementing a poor-man's intersection-type.
    • and this approach means you can use a struct implementation of IReadOnlyOrder, IIs<Order> without boxing the argument value, which helps with performance at scale, while still using the exact same single generic method to handle class implementations too.

You might suggest that instead of using IIs<Order> an interface IMutableOrder could be used instead (which is just like IReadOnlyOrder, except all the properties are read/write, instead of read-only), but the problem with IMutableOrder is that any type can still implement IMutableOrder which would break the DbContext at runtime if implemented by any type other than class Order, whereas with the TOrder : IIs<Order> generic constraint you're making use of a compile-time guarantee that whatever object is passed as an argument you'll always be able to get the underlying Order object out of it.

Obviously this example is somewhat contrived - and this is a somewhat narrow-use-case too - but I've found the interface IIs<T> type essential in other situations too, especially when I'm using a readonly struct as a predicate-type - for the same general reasons as above: wanting to preserve object-identity and the ability to directly get-at a underlying data objects regardless of the wrapper type (indeed, whether it's a struct or a class!), and with compile-time guarantees that it won't fail at runtime.

Given the sheer simplicity and utility of an interface IIs<T> I'm really surprised that .NET doesn't have it already...

[Xyncgas]

I hope the power goes out in my district so I can get the courage to go to the park and touch some grass and look at all this codes

[Xyncgas]

I never use EFC or SQL, NOSQL is my choice so I guess we are living in different world. Today I had to deal with ordering things too and I ended up just putting a bunch unsorted stuffs that was pulled into a sorted list