[Proposal] Multi-interface type

[ds1709]

Summary

Allow to create multi-interface type variables, fields, parameters and so on.

Motivation

Some times it may be useful to work with some object knowing it implements more than one interface. Implementing aggregating interface in this case can be overengineering.

Current situation (C# 9)

interface IHasX
{
    int X { get; set; }
}

interface IHasY
{
   int Y { get; set; }
}

class Foo
{
    private readonly IHasX x;
    private readonly IHasY y;

    // 'x' and 'y' can't be specific type object, but shoud be same object, implementing both interfaces
    public Foo(IHasX x, IHasY y)
    {
        if(!ReferenceEqual(x, y))
            throw new InvalidOperationException("x and y shoud be same object");

         // can't be stored in single field;
         this.x = x;
         this.y = y;
    }

    void DoSome(object obj)
    {
        if (obj is IHasX x and IHasY y)
        {
             x.X++;
             y.Y++;
        }
    }
}

Possible workaround (requires rewriting of existing code)

interface IHasXY: IHasX, IHasY
{
}

class Foo
{
    private readonly IHasXY xy;

    public Foo(IHasXY xy)
    {
        this.xy = xy; // can be stored in single field.
    }

    void DoSome(object obj)
    {
        if (obj is IHasXY xy)
        {
             xy.X++;
             xy.Y++;
        }
    }
}

With multi-inerface types

class Foo
{
    private readonly (IHasX, IHasY) xy;

    // 'x' and 'y' can't be specified as 'solid' type, guarantee single object, implementing both interfaces
    public Foo((IHasX, IHasY) xy)
    {
        this.xy = xy; // can be stored in single field.
    }

    void DoSome(object obj)
    {
        if (obj is (IHasX, IHasY) xy)
        {
             xy.X++;
             xy.Y++;
        }
    }
}

[Phantonia]

If #399 is realised, the syntax for the multi-interface type would be IHasX & IHasY

[gulshan]

Or IHasX + IHasY similar to Rust-

private readonly (IHasX + IHasY) xy;

[theunrepentantgeek]

What's wrong with using generics?

public interface HasX
{
    void X();
}

public interface HasY
{
    void Y();
}

public class C {
    public void Perform<T>(T t) 
        where T: HasX, HasY
    {
        t.X();
        t.Y();
    }
}

[Phantonia]

There is no straight-forward way to save an IHasX & IHasY as a field. You could use a generic factory method:

class Foo
{
    private readonly object xy;

    private Foo(object xy)
    {
        Debug.Assert(xy is IHasX and IHasY);
        this.xy = xy;
    }
    
    public static Foo Create<T>(T xy) where T : IHasX, IHasY
    {
        return new Foo(xy);
    }
}

or

class Foo
{
    private readonly IHasX x;
    private readonly IHasY y;

    private Foo(IHasX x, IHasY y)
    {
        Debug.Assert(ReferenceEquals(x, y));
        this.x = x;
        this.y = y;
    }
    
    public static Foo Create<T>(T xy) where T : IHasX, IHasY
    {
        return new Foo(xy, xy);
    }
}

However, both options seem pretty suboptimal (plus, I think, the second version is buggy for structs that implement IHasX and IHasY).

[ds1709]

What's wrong with using generics?

There's nothing 'wrong', it's 'another'. You are not able to use generics everywhere you want. For example, it can be overriding of some method like, like

abstract class Foo
{
    public abstract Do(Bar bar);
}
sealed class Foo2 : Foo
{
    public override Do(Bar bar) // can't be generic
    {
        if (bar is IHasX x and IHasY y)
        {
             x.X++;
             y.Y++;
        }
    }
}

Also, introducing generics in such scenarios can be architectural overengineering.

[foxesknow]

It wouldn't work for constructors, which can't be generic.