Discussion: indexer overloading based on the ref-ness of the return type

[alrz]

It helps you to provide ref indexers without breaking existing code.

class ArrayBuilder<T>
{
  public ref T this[int index]
    => ref array[index];

  public T this[int index] {
    get => array[index];
    set => array[index] = value;
  }
}

class ImmutableArray<T>
{
  public readonly ref T this[int index]
    => ref array[index];

  public T this[int index]
    => array[index];
}

Usage:

ref var item =  ref builder[index]; // calls the ref indexer
var item  = builder[index]; // calls the non-ref indexer

Note: afaik clr is capable of overloading based on return type.

Open question: should we restrict this so that both indexers required to return the same type?
Open question: is it useful to allow this also for other members?

[svick]

How would overload resolution work in that case? Would the ref indexer be always preferred and the normal indexer would exist only for binary backward compatibility?

[alrz]

@svick

If you use ref builder[index] it calls the ref indexer, in all other cases the non-ref indexer would be called.

[jjvanzon]

@alrz

Open question: is it useful to allow this also for other members?

Yes, properties please:

public string Text => ref labelTitle.Text;

Instead of:

public string Text
{
    get => labelTitle.Text;
    set => labelTitle.Text = value;
}

[svick]

@janjoostvanzon That already works, this si valid C# 7 code (assuming labelTitle.Text is a field):

public ref string Text => ref labelTitle.Text;

The question here is whether it should be allowed to have both versions at the same time:

public ref string Text => ref labelTitle.Text;

public string Text
{
    get => labelTitle.Text;
    set => labelTitle.Text = value;
}

[jjvanzon]

labelTitle.Text is not a field. It's a property.

[svick]

@janjoostvanzon Then you can't return it by ref. If you want this just as a shorthand, then that's a completely different proposal.

[jjvanzon]

I understand now, that your question is about resolving the ambiguity between similar members that only differ by whether they are ref or not. I must have been too sleepy when I responded.

However, you gave me ideas, not directly related to your question.

[jjvanzon]

Since there can also not be overloads that differ by just the return type, it seems strange that there could be overloads that only differ by whether they return ref. Does that make sense?

I question whether you should be able to add both a ref and non-ref variation at all, and whether you should be able to see from the outside whether it is ref at all:

So I think this:

 public T this[int index] => ref array[index];

could be a better syntax than:

 public ref T this[int index] => ref array[index];

If the language worked like that, your compatibility / ambiguity issue would be gone.

[HaloFour]

@janjoostvanzon

Even if the language did work like that the CLR does not. The return type is either T or T&, it can't be both. That ref in the return type is necessary. The behavior of the method is quite different without it. You'd be required to have two methods, overloaded by return type, which of course the CLR allows.

What concerns me about this proposal is how it would play out when you attempt to consume that method from other languages. Does the CLS allow for overloading based only on return type? What is the stance on ref returns in the CLR at all?

[svick]

Now that I think about it, I wonder if supporting named indexers (#471) and using them wouldn't be a cleaner solution. E.g.:

class ArrayBuilder<T>
{
  // might need a better name
  public ref T ByRef[int index]
    => ref array[index];

  public T this[int index] { 
    get => array[index];
    set => array[index] = value;
  }
}

…

ref var item =  ref builder.ByRef[index]; // calls the ref indexer
var item  = builder[index]; // calls the non-ref indexer

It means using the by-ref indexer is more verbose, but since it's a fairly niche feature, that might be okay. And it also means avoiding confusing overloading by return type.

[alrz]

@svick

In that case, we could be using a regular method instead; I don't think using a pair of brackets instead of parentheses is worth doing a feature (#471), also, you are suggesting an alternative that requires slightly more work (like syntax change and dealing with ambiguities) and IMO it would not get past 1000 points to make the cut. ref/non-ref indexers already supported for arrays and it wouldn't be ambigious in any way. I think clr support is a good opportunity to relax rules and take advantage of the mandatory ref operator to provide a consistent syntax over types. Regardless of ref being a niche feature or just a new feature, I do not think that introducing named indexers can remotely address the use case here.

[jjvanzon]

@alrz
Immitating an indexer with methods would require 2 methods: one for the setter and one for the getter. You may as well say we don't need properties, because we could also do that with methods.

[alrz]

Imitating an indexer with methods would require 2 methods

I don't believe that's the case for a ref-returning indexer.