Feature Request: Support a single return with multiple types.

[myermian]

I was writing a method that was originally returning an IEnumerable<int>, but then I reached the point that I also needed to ensure that the type I return implements INotifyCollectionChanged. I realized that my options were the following:

1. Create an interface that implements both of those interfaces, then return that type instead. This wasn't good because types such as ObservableCollection<int> would have no way of knowing my interface, so I couldn't use those as the concrete return type.
2. Make my type (or class) generic, so that the caller could specify a type that fits within my constraints: public T GetFoos<T>() where T : IEnumerable<int>, INotifyCollectionChanged { ... }. This wasn't good because my method became very ugly and now I expect the callers to specify the collection type I want to use! Not only that, if I put the generic constraint on my class and had 2-3 methods that required this pattern then my class becomes ridiculously messy!
3. Return a concrete type: public ObservableCollection<int> GetFoos() { ... }.

I couldn't think of any other options, so I went with option 3. This wasn't an issue in my case since the code is self-serving (private internal code). However, this would have been annoying if I was writing a public api because I now forced myself to always return ObservableCollection<int> (or a derivative of that type) unless I am willing to introduce a breaking change. I'm wondering if there is any way to support specifying multiple interfaces as a return type? Something along the lines of the following:

public (IEnumerable<int>, INotifyCollectionChanged) GetFoos()
{
    return new ObservableCollection<int>();
    // or return new ReadOnlyObservableCollection<int>();
    // or return new MyCustomCollectionThatSatisfiesBothInterfaces<int>();

    // return new Collection<T>(); -- Compilation Error!
}

The caller would now be able to take advantage of both interfaces, just as it would if it was a generic T with constraints. But, I could swap out the concrete type in the future if I decided to do so without causing the code to break. Keep in mind, I'm not saying that the behavior might not be different, as that is based on the implementation of the concrete type, but the contract itself is not broken -- I would still return a type that implemented both interfaces.

Also, keep in mind that I am not advocating for the example syntax as the required syntax. The syntax itself is not the important part (it is just an example of a possible way to convey the feature); the important part is the feature/behavior itself.

[KalitaAlexey]

#2146 will be good for your purpose
And your way to specify returning type is ugly and also did you think about how a developer will be write type of variable for combined type?

[myermian]

#2146 will be good for your purpose

Good to know that the feature suggestion is out there already.

And your way to specify returning type is ugly and also did you think about how a developer will be write type of variable for combined type?

I was not advocating the exact syntax, I was advocating the behavior, as I specifically said:

"Also, keep in mind that I am not advocating for the example syntax as the required syntax. The syntax itself is not the important part (it is just an example of a possible way to convey the feature); the important part is the feature/behavior itself."

[gafter]

Covariant returns are proposed for C# 7, and that would also solve this.