Proposal: Support setter-only indexers of multiple value types, but same indexer type, and fix indexer implicit conversion/overload "bug"

[wrighp]

Summary

• The compiler should be able to support multiple setter-only indexers of differing value types when index parameter(s) are the same, with up to one getter that uses that same indexer signature (like normal), like with method overloads.
• The compiler should also properly recognize implicit conversions into indexers when there are multiple indexers, like with method overloads (possibly a bug/unintended behavior)

Explanation: Ambiguity

Currently when creating indexer setters on their own, the compiler treats them as ambiguous, even though their method representation would otherwise be non-ambiguous:

public class MixedIndexer
{
    private Dictionary<string, string> stringValue = new();
    private Dictionary<string, int> intValue = new();
	
    public string this[string key] { set => stringValue[key] = value; }
    public int this[string key]  { set => intValue[key] = value; }
}

This leads to a compilation error of CS0121 The call is ambiguous between the following methods or properties: 'MixedIndexer.this[string]' and 'MixedIndexer.this[string]', even though there is no actual ambiguity here, due to the lack of getter.

Below is a synonymous overload that accomplishes the same thing, it is clear that it is not ambiguous:

public void Set(string key, string value);
public void Set(string key, int value);

Explanation: Implicit

Similarly, if you were to try and work around this with a separate type of key you come across a failure for the compiler to recognize implicit conversions to indexers when using more than one indexer:

public class MixedIndexer
{
    private Dictionary<string, string> stringIndex = new();
    private Dictionary<string, int> intIndex = new();

    public string this[string key] { set => stringIndex[key] = value; }
    public int this[ProxyString key]  { set => intIndex[key] = value; }

    public void Set(string key, string value) => stringIndex[key] = value;
    public void Set(ProxyString key, int value) => intIndex[key] = value;
}
public readonly struct ProxyString
{
    private readonly string value;
    public ProxyString(string value) => this.value = value;
    public static implicit operator ProxyString(string value) => new ProxyString(value);
    public static implicit operator string(ProxyString proxyString) => proxyString.value;
}

var indexer = new MixedIndexer();
indexer.Set("key", 1234); //Implicitly converts to ProxyString and is valid
indexer.Set("key", "myString");

indexer["key"] = 1234; //CS0029 Cannot implicitly convert type 'int' to 'string'	
indexer["key"] = "myString";

It is worth noting that implicit conversion into indexers is normally okay if there is a single one, however with multiple it breaks. This could be broken down into a separate issue, but implementation is likely tied together with how the overloads (or lack thereof) work for indexers.

Motivation/User Story/Okay, but why?

I am currently working on a lua-like table class(blackboard design pattern) that takes in various value types , and I would like to support multiple setters with the same indexer key, but different value types (and one common getter). The purpose is so that the table can take in various struct and primitive types for optimization purposes without having to box them as objects and reinterpret them conditionally when the type is already known.

As an alternative I am currently just using a method-based Set(), but not only would I like to use the indexers, LLM's like Copilot also prefer to use indexers in this manner, and even if it isn't currently possible, it feels like it should be logically consistent with normal method overloading techniques to allow this behavior.

[timcassell]

I think type unions will solve this case. You can work around it today by making your own union type.

public struct Union<T1, T2>
{
    public int type;
    public T1 o1;
    public T2 o2;
    
    public static implicit operator Union<T1, T2>(T1 value) => new() { type = 0, o1 = value };
    public static implicit operator Union<T1, T2>(T2 value) => new() { type = 1, o2 = value };
}

public class MixedIndexer
{
    private Dictionary<string, string> stringValue = new();
    private Dictionary<string, int> intValue = new();
	
    public Union<string, int> this[string key]
    {
        set
        {
            switch (value.type)
            {
                case 0: stringValue[key] = value.o1; break;
                case 1: intValue[key] = value.o2; break;
            }
        }
    }
}

Or you can use a library like OneOf.

[wrighp]

@timcassell If you have many types then the struct copies grow too large as the struct grows linearly with the OneOf approach. In addition to having to switch in the hotpath which is not ideal (when you and the compiler already know the type). A better option is to use FieldOffsetAttribute to write unmanaged types in the same memory location but you still have to select it, but then the struct must default to the largest size unmanaged struct within it, plus an additional object pointer (as they are not allowed to overlap by the runtime), plus the selector enum.

I understand there are alternatives, but it's unnecessary when the compiler has the info.

[HaloFour]

Even though properties are implemented as methods and the setter methods in this case would not be ambiguous that doesn't mean that philosophically C# should treat them simply as overloads. Even if that ultimately weren't an issue, it still feels like a compiler feature designed to solve exactly one use case. I'd want to know where else something like this could be generally useful, where any of the different existing alternatives are simply not suitable.