[API Proposal]: ActivatorUtilities.CreateFactory<T> with params span

[alrz]

Background and motivation

The arguments passed to CreateFactory and ObjectFactory are usually of a fixed number so it may be worthwhile to consider params span for both instead of array.

API Proposal

I haven't seen an addition like this so far so I'm not sure about the naming convention.

namespace Microsoft.Extensions.DependencyInjection
{
  public delegate T ObjectFactoryWithParams<out T>(IServiceProvider serviceProvider, params ReadOnlySpan<object?> arguments); 

  public static class ActivatorUtilities
  {
    public static ObjectFactoryWithParams<T> CreateFactory2<T>(params ReadOnlySpan<Type> argumentTypes)
  }
}

API Usage

var factory = ActivatorUtilities.CreateFactory<T>(typeof(SomeType));
var result = factory(serviceProvider, new SomeType());

Alternative Designs

An alternative is to consider making the return type a generic delegate over argument types.

public static ObjectFactory<TArg1, T> CreateFactory<T, TArg1>();
public static ObjectFactory<TArg1, TArg2, T> CreateFactory<T, TArg1, TArg2>();
// etc

public delegate T ObjectFactory<in TArg1, out T>(IServiceProvider serviceProvider, TArg1? arg1);
public delegate T ObjectFactory<in TArg1, in TArg2, out T>(IServiceProvider serviceProvider, TArg1? arg1, TArg2? arg2);
// etc

var factory = ActivatorUtilities.CreateFactory<T, SomeType>();
var result = factory(serviceProvider, new SomeType());

Risks

No response

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-extensions-dependencyinjection
See info in area-owners.md if you want to be subscribed.

[alrz]

@steveharter could this be a candidate for API review alongside #101829?

[steveharter]

@steveharter could this be a candidate for API review alongside #101829?

Yes this is a good proposal; however the window for 9.0 has been closed for such changes.

[halter73]

The alternative design seems more appealing to me if we do anything here. The goal appears to be to reduce allocations, but params ReadOnlySpan<object?> arguments still forces you to potentially box the individual arguments.

We might as well go all the away and do the most optimal thing if we're going to define new CreateFactory overload(s), but I think we should probably just return a Func<in T1, out TResult> instead of an ObjectFactory<in TArg1, out T>.

[terrajobst]

Video

• It seems to odd to have an API that avoids the array allocation, given how expensive the call is
• The alternative design makes more sense to use, at least the returned delegate is strongly typed to the arguments
  • We'd probably prefer Func<...> over creating 15 new delegate types

namespace Microsoft.Extensions.DependencyInjection;

public delegate T ObjectFactoryWithParams<out T>(IServiceProvider serviceProvider, params ReadOnlySpan<object?> arguments);

public static class ActivatorUtilities
{
    public static ObjectFactoryWithParams<T> CreateFactory2<T>(params ReadOnlySpan<Type> argumentTypes);
}

[alrz]

If Func<...> is preferred, might as well take it as a type argument.

public static class ActivatorUtilities
{
    public static T CreateFactoryOf<T>() where T : Delegate;
}

var factory = ActivatorUtilities.CreateFactoryOf<Func<IServiceProvider, SomeType, T>>();
var result = factory(serviceProvider, new SomeType());

This way only one overload would be added. this will avoid array allocation and boxing, but also typechecks that the callsite matches the factory.

[alrz]

As a result of discussion here I opened up #111228 which I think is more straightforward to implement since that's how ActivatorUtilities already works internally.