Overloading methods that accepts delegates which differs in nullability

[HazyFish]

class Indexer<T>
{
    void Index(Func<T, string> selector)
    {}
    
    void Index(Func<T, string?> selector)
    {}
}

The above code does not compile due to the following error:

CS0111: Type 'Indexer' already defines a member called 'Index' with the same parameter types

However, I want to determine whether selector selects a nullable value or not.

I could use different names instead of overloading but that would negatively impact the library user experience.

Is there any other solutions to this besides avoiding overloading?

[TahirAhmadov]

You can define your own delegate types, but if these are simple delegates along the lines of Func<T, string>, it can create other issues, such as your delegate type not being directly assignable to/from Func<T, string> - in case there are other dependencies.

[HazyFish]

I just tried it out, looks like defining my own delegate types works, but when I use it without explicitly specifying the delegate type, it gives The call is ambiguous between the following methods or properties.

[Richiban]

The problem is that nullable reference types are a compile-time only feature. According to the runtime Func<T, string> and Func<T, string?> are the same, just with different nullability annotations.

[TahirAhmadov]

@HazyFish yes you are right of course, with the main usage scenario being supplying a lambda/delegate, the custom delegate types don't work, either.

Looking at your snippet now, I tend to agree with @iam3yal that a different name is in order here, because the difference is so subtle that you want to make sure users know what they are calling - even if C# supported overloading on nullability (which it doesn't).

[iam3yal]

One more thing to consider is what happens if someone slips in something like x => null! if he didn't check for null already and he/she expects different outcome based on whether the selector returns null then now there is a bug in the system so it's a bit odd.

[iam3yal]

@HazyFish

Is there any other solutions to this besides avoiding overloading?

Well, the answers above should address your question but even if this was possible any particular reason this is desired? I mean it might worth considering different names.

[HazyFish]

The use case is that I'm writing a mapper for a search engine database (namely typesense). I would want users to map common C# types to Typesense field types with type safety and good DX. That's why I think it might be a good idea to overload based on nullability.

I agree it might be better to use different names, and here is how I implement it.

public static class FieldCreator<TDocument>
{
    public static Field Create(Expression<Func<TDocument, string>> memberSelector, bool facet)
        => new(memberSelector.GetTypesenseFieldName(), FieldType.String, facet: facet, optional: false);

    public static Field CreateOptional(Expression<Func<TDocument, string?>> memberSelector, bool facet)
        => new(memberSelector.GetTypesenseFieldName(), FieldType.String, facet: facet, optional: true);

   // ...
)

internal static class ExpressionExtensions
{
    public static MemberExpression GetMemberExpression<T, TMember>(this Expression<Func<T, TMember>> memberSelector)
        => memberSelector.Body as MemberExpression
        ?? throw new ArgumentException("Expression body must be a member expression", nameof(memberSelector));

    public static string GetMemberName<T, TMember>(this Expression<Func<T, TMember>> memberSelector)
        => memberSelector.GetMemberExpression().Member.Name;

    public static string GetTypesenseFieldName<T, TMember>(this Expression<Func<T, TMember>> memberSelector)
        => JsonNamingPolicy.CamelCase.ConvertName(memberSelector.GetMemberName());
}