How to handle conflicting function names when implementing multiple interfaces?

Question

I have an interface defined in C# that implements IEnumerable. The implementation of the interface will be done in C++/WinRT as it needs direct access to native code. When I attempt to implement this interface using C++/WinRT, the generated header/implementation contains two 'First()' functions (one from IIterable, and one from IBindableIterable) with different return types. Obviously this isn't going to compile.

Is there some way to "rename" one (or both) of the conflicting functions in the IDL file? C++/CX had a work around that allowed you to use a different function name and then 'bind' it back to the interface name.

Simplified example code below:

Interface:

public interface IUInt32Array : IEnumerable<uint> {}

IDL:

[default_interface]
runtimeclass UInt32Array : IUInt32Array
{
    UInt32Array(UInt32 size);
}

IDL Generated Header:

struct UInt32Array : UInt32ArrayT<UInt32Array>
{
    UInt32Array(uint32_t size);
    Windows::Foundation::Collections::IIterator<uint32_t> First();  // <-- Problem
    Windows::UI::Xaml::Interop::IBindableIterator First();          // <-- Problem
}

Answer 1

A solution for this specific problem is to use a combination of 'auto' as the declared return type for the First() function implementation, and to return a type with conversion operators for the two different return types.

Here is an example showing how this was solved in the CppWinRT source code. The linked source code is for the base_collections_vector.h header, specifically see the convertible_observable_vector::First() function (replicated below).

    auto First() {
        struct result {
            container_type* container;

            operator wfc::IIterator<T>() {
                return static_cast<base_type*>(container)->First();
            }

            operator wfc::IIterator<Windows::Foundation::IInspectable>() {
                return make<iterator>(container);
            }
        };
        return result{ this };
    }

Notice here that the function itself is defined as returning auto, which allows us to return an intermediate type. This intermediate type then implements conversion operators for converting to the type expected by the caller. This works for this particular problem as the generated CppWinRT source code immediately assigns the result of the call to a value of the expected type, thus immediately causing the invocation of the conversion operators which in turn return the final correct iterator type.

Thanks to Kenny Kerr who pointed me at both the example and a write-up explaining the above.