Regression: overload resolution changed in the language preview

[ds5678]

Version Used:

Visual Studio 2022 Community Edition, 17.14.0 Preview 4.0

.NET 9

Steps to Reproduce:

public sealed class Utf8String
{
    public static implicit operator Utf8String(ReadOnlySpan<byte> data)
    {
        return new();
    }
}
internal sealed class CustomBinaryWriter() : BinaryWriter()
{
    public sealed override void Write(byte[] buffer)
    {
        Console.WriteLine("Latest Language Version");
    }

    public void Write(Utf8String utf8String)
    {
        Console.WriteLine("Preview Language Version");
    }
}
internal static class Program
{
    static void Main()
    {
        byte[] buffer = new byte[10];
        CustomBinaryWriter writer = new();
        writer.Write(buffer);
    }
}

I'd speculate that this is caused by first class span, but I did no internal investigation of the compiler.

Expected Behavior:

The compiler should decide that Write(byte[]) is the better overload because it has an exact type match.

Actual Behavior:

byte[] is implicitly converted to ReadOnlySpan<byte> and then to Utf8String, so Write(Utf8String) is chosen.

[jjonescz]

First-class spans only cause public void Write(Utf8String) to be an applicable overload when it previously wasn't. Which is an expected behavior.

The fact that public void Write(Utf8String) is preferred over public sealed override void Write(byte[]) is because the latter is an override. Those are pre-existing C# rules.

Compare with the following similar example where M(long) is chosen (the output is 2) and there are no first-class spans involved:

using System;

new C().M(0);

sealed class C : B
{
    public override void M(int i) => Console.Write(1);
    public void M(long i) => Console.Write(2);
}

abstract class B
{
    public virtual void M(int i) => Console.Write(0);
}

[ds5678]

I found notes in the proposal about my issue.

https://github.com/dotnet/csharplang/blob/main/proposals/first-class-span-types.md#user-defined-conversions-through-inheritance

Given the LDT's usual apprehension towards breaking changes (especially silent ones like mine), I'm surprised that they approved this feature. In my opinion, the value of this feature as-is does not eclipse the "minus 100 points" requirement for implementation, especially when considering alternatives like using a marker attribute (similar to overload resolution priority) or using source generators (current solution).

because the latter is an override. Those are pre-existing C# rules.

I think it was a mistake not to include the whole type hierarchy in overload resolution, rather than iterating up. However, it's almost certainly too late to change that now.

[RikkiGibson]

It feels a bit unfortunate that in order to both 'override Write(byte[])', and have it win over a non-override in overload resolution, there is a need to insert intermediate base class, as best as I can tell. Possibly other workarounds exist, I am not sure. SharpLab

In this specific case, it might be good to mitigate by declaring ReadOnlySpan<byte> overload in the derived type.

[jjonescz]

Given the LDT's usual apprehension towards breaking changes (especially silent ones like mine)

It's true there are silent breaking changes as part of first-class spans, but the expectation is that if you have methods that take inputs that are convertible to each other and the methods have the same names, they are interchangeable, so those breaks shouldn't be actually observable. E.g., the simplest case of an expected break from this feature is that calls to Join(IEnumerable<T>) can now bind to Join(ReadOnlySpan<T>) instead. Those methods should do the same thing, just one of them was likely less performant since it operated on IEnumerable instead of span.

[CyrusNajmabadi]

FWIW, ahving an api that takes both a UTF8String (which i think of as already clearly being a span of bytes) and an array of bytes... then i get a bit confused. How do these differ?

[ds5678]

FWIW, having an api that takes both a UTF8String (which i think of as already clearly being a span of bytes) and an array of bytes... then i get a bit confused. How do these differ?

When written, the string is length-prefixed. The array is just written as arbitrary data.

[CyrusNajmabadi]

When written, the string is length-prefixed. The array is just written as arbitrary data.

FWIW, that would be surprising and/or unexpected to me. And would def be something i would trip on. This would esp. be true given the implicit allowing of any and all byte arrays to be utf8strings.

[ds5678]

When written, the string is length-prefixed. The array is just written as arbitrary data.

FWIW, that would be surprising and/or unexpected to me. And would def be something i would trip on.

Write(string) is length-prefixed.

This would esp. be true given the implicit allowing of any and all byte arrays to be utf8strings.

When writing the Utf8String class, I debated whether the conversion operator should be implicit or explicit.

Utf8String s1 = "Hello world!"u8;
Utf8String s2 = (Utf8String)"Hello world!"u8;

The former was more visually pleasant to me, even if I disliked how it hides an array allocation.