Ability to apply type hints to delegates (unknown number of arguments, f.i. ASP.Net minimal API)

[mycroes]

I'm currently working a lot with methods that in the most basic usage expect simple things like projections (Expression<Func<TIn, TOut>>) or transformations (Func<TIn, TOut>). However, as with ASP.Net Core minimal API, I want consumers to be able to use services as well. This is achievable by adding an additional method with an additional generic argument, however one would need to extend this in case a second, third, fourth, ... service are to be injected. Delegates are the obvious way to escape this, but delegates and anonymous types are not best buddies. See the following example of this situation in a CRUD framework:

public class UserEntity
{
    public int Id { get; set; }
    public string Username { get; set; }
    public string FullName { get; set; }
    public bool SubscribedToNewsLetter { get; set; }
    public string PasswordHash { get; set; }
}

public abstract class CrudFor<TEntity>
{
    protected IModelConfiguration<TEntity, TModel> Model(Expression<Func<TEntity, TModel>> projection) { ... }
}

public interface IModelConfiguration<TEntity, TModel>
{
    void CreateWith(Func<TModel, TEntity> factory);
}

public class UserCrud : CrudFor<UserEntity>
{
    public UserCrud()
    {
        Model(u => new { u.Username, u.FullName, u.SubscribedToNewsLetter })
            .CreateWith(model => {
                var entity = new UserEntity
                {
                    Username = model.Username,
                    FullName= model.FullName,
                    SubscribedToNewsLetter = model.SubscribedToNewsLetter,
                }
                return entity;
            });
     }
}

So far so good. This works exactly as desired and C# can infer the anonymous model type TModel that's the output of the projection. However, now if I want to connect the newsletter subscription to an external API, I'm going to have to inject that into the handler somehow. I could do that using a method void CreateWith<TService>(Func<TModel, TService, TEntity> factory). The next issue will be that in some cases I'd want to be able to have async handling, so I will also need to add overloads for Task<T> and ValueTask<T> returns, possibly even more if there are other awaitable types that make sense to support, while also retaining the direct T support for the really simple callbacks.

The obvious way out is to support the following signature: CreateWith(Delegate factory), which also happens to be what ASP.Net Core supports for declaring minimal API handlers. Borrowing from that very same minimal API, we can take such a factory delegate, inspect it's input types, inspect it's output type and bring this all back to Func<HttpContext, TModel, Task<TEntity>>) using a tiny bit of expression wiring. However, this overlooks the part of specifying the factory delegate, because now the input types have to be declared inline and one of my input types is the anonymous TModel, which I can't specify. One might argue that partial generic argument specification might help here, but I don't yet see how to apply that here and also I guess that's still not on the radar for release soon.

So let's continue down the broken path and see what can be fixed. While a Delegate fixes the issue of the unknown / unspecified arguments, it opens the issue of making the known inputs unknown. We can make a combination though, by having CreateWith(Func<TModel, Delegate> wrappedFactory). With a bit of expression wiring we can still reduce this down to Func<HttpContext, TModel, Task<TEntity>>, which will invoke wrappedFactory and then invoke the returned delegate with the required services.

Again, so far so good. However, I've now lost the return type. While this is fine in the case of my create statement, I'm running into situations where I want to return yet another derived expression. Typing those expressions during compile time is impossible because I can't specify the return type for the Delegate argument. However, if I could somehow hint the compiler that my Delegate needs to have a return of Expression<Func<TEntity, TModel>> (or whatever combination of TEntity and TModel that would require specifying the type for TModel), this is solvable as well.

Because delegates logically can't implement interfaces, there's no approach there. I'd imagine the least invasive way might actually be an attribute that declares the return type, but honestly I'm baffled I can't find anyone having the same issue and same solution, which leads me to think there must be an oversight in what I'm trying to achieve. Besides the return, I could also imagine one would want to declare required input arguments in a delegate. It would actually be possible to make this quite strict, declaring that the delegate has arguments X, Y, Z, in that exact order, but not constraining any arguments that would follow.

Can someone please provide a bit of feedback on the above? I'm guessing it would be possible to create this as a library and roslyn generator, although I'm not sure if it's possible to inject the types from a generator. Any comments are greatly appreciated!

[jaredpar]

However, this overlooks the part of specifying the factory delegate, because now the input types have to be declared inline and one of my input types is the anonymous TModel, which I can't specify.

I'm not following this part: at the point your input types are specified TModel is going to be a concrete model that can be specified. Can you try putting a bit more code here to help illustrate the problem you are hitting?

[mycroes]

Sure, these are the modifications to the sample above:

public interface IModelConfiguration<TEntity, TModel>
{
    void CreateWith(Delegate factory);
}

public class UserCrud : CrudFor<UserEntity>
{
    public UserCrud()
    {
        Model(u => new { u.Username, u.FullName, u.SubscribedToNewsLetter })
            .CreateWith((INewsLetterApi newsLetterApi, /*anonymous type*/ TModel model) => {
                var entity = new UserEntity
                {
                    Username = model.Username,
                    FullName= model.FullName,
                    SubscribedToNewsLetter = model.SubscribedToNewsLetter,
                }

                newsLetterApi.SendSpam(entity.Username);

                return entity;
            });
     }
}

I've replaced the CreateWith parameter with Delegate to permit the injection of INewsLetterApi, however, the TModel identifier is not in scope in the UserCrud ctor.

Further on I explain that I can work around this specific issue as follows:

public interface IModelConfiguration<TEntity, TModel>
{
    void CreateWith(Func<TModel, Delegate> factory);
}

public class UserCrud : CrudFor<UserEntity>
{
    public UserCrud()
    {
        Model(u => new { u.Username, u.FullName, u.SubscribedToNewsLetter })
            .CreateWith(model => (INewsLetterApi newsLetterApi) => {
                var entity = new UserEntity
                {
                    Username = model.Username,
                    FullName= model.FullName,
                    SubscribedToNewsLetter = model.SubscribedToNewsLetter,
                }

                newsLetterApi.SendSpam(entity.Username);

                return entity;
            });
     }
}

However, as you can see this still loses the return type in the method declaration. That's fine in this case, but let's say I want to define a filter for a table with IModelConfiguration.AddFilter(Func<Expression<Func<TModel, bool>>>). This works, but adding services to the mix again will either require me to add overloads for any number of services. Which of course is what's there in the CLR for some types as well, but it's really cumbersome to do such things and especially to repeat that pattern across different implementations with their own implementation details that prevent reuse. I've opted to implement up to 3 service arguments in some cases, but preferably I'd find the escape hatch that would permit some form of type hinting for the Delegate parameters.

[mycroes]

I'm thinking that if a Delegate<TResult> was added, which would behave very similar to Delegate and be a viable generic type constraint for Func<TResult> and Func<T1, ..., TResult> this might actually be fixable already. Func<TModel, Delegate> would then be either Func<TModel, Delegate<DesiredReturnType>> or Func<TModel, TDelegate>> where TDelegate : Delegate<DesiredReturnType>. I can hardly imagine noone has ever considerd adding a Delegate<TReturn> though, but my search yesterday didn't yield anything useful.

[mycroes]

One more that I'm running into: The model projection might want to use services as well. This might be because someone wants to inject a DbContext to get i.e. the last login attempt for the user, or maybe someone wants to inject AppSettings of some sort to compare a date. However, if I change CrudFor<TEntity>.Model<TModel>(...) to take a Delegate instead, I lose the TModel generic argument. This would again be fixed if there was a Delegate<TResult>, so that I could type the method as CrudFor<TEntity>.Model<TModel>(Delegate<Expression<Func<TEntity, TModel>>> projectionFactory). I'm almost at the point thinking Delegate<TResult> would solve hunger worldwide.

[jaredpar]

Thanks. This particular part got the point across:

  Model(u => new { u.Username, u.FullName, u.SubscribedToNewsLetter })
            .CreateWith((INewsLetterApi newsLetterApi, /*anonymous type*/ TModel model) => {

Essentially there is no middle ground with types in lambda signatures: once you specify one you have to specify all. That is troublesome when one of the types is going to be an anonymous type which is unspeakable.

In this case though why do you need the INewsLetterApi type annotation? The sample will compile just fine without it.

https://sharplab.io/#v2:D4AQTAjAsAUCAMACEEB0AZAlgOwI6oFEAPABwCcBTAZyswHtsqBuWEAZmTEQGFEBvWIiHIOIACyIAsgAoAlP0HCAvrBUxWorgFUqFMgWwAXTIYCesATGEjEOQ4gCSAE36IA5hUNNEur4jXW7MgQSDp62ACGALYUrh5+vt4BwkEoSABiAK4ANtkActGxfO6e3on+ikJBAEZ0dNmIAMqZ1VQAxmSY1RROACp0eRQA7lTonoZ6caU+08lVoiGIAAoRNEN0ZE4AEqsAFlMJs6qwGogRrYZkEW324DxkmU7pGwA8vQbGZgB8FpWI5HQJjceo5JHQnBRstwGAAzTBuTJXYwMN4fEymAA0iF6YIh2S+UnBkLeuMhX2kxHI1FoKJAAFZUUZ0VicUT8QSAQArCg3ejYeQAXgJ2By2RYMDUpzsehh11iDlJUNh8MREWR2EZn0x2MVPxglkCEm4lDVFAA6iZdtIACKQihuU2IWU3DamWTiyVwTSIMJkY2PRAALnuj2eZBevrR31+VhSHF9/qccj+BuswkV0kyiCFiGww1cmVQvsiMSxhayuQKpcQhearQ6XR6/UGIzGhgmZH8sj+aeEqGNFFNFsMVukedb4z0AEESJgsQB6ABUEWwDFMUTomSoiDMJAoi/nQg3eMFBNTvYviAAbhFOxQmWZs7n85GH+ZY5fe+fP5fi4Un8ekJFroZAlhQGI9j+aYVvkhQCoggHZKgMFVuBkFQcIdbtJ03R9AMwyjJOnbwYhqBYQ2uHNgRbYdhBH4YRU6j0Rh46Ee206zmR95OI0JDRNI95asB4SFO6JzMVBIAAOyIIJ6LihhShicxahKEAA

[mycroes]

You're missing a semicolon after the new UserEntity { ... }, of course it can't magically infer the type 😄

About the generic types... There is a middle ground by having the Func<TModel, Delegate>, but then I miss out on the return type.

Delegate<TReturn> would actually be a huge help here. Do you know if such a thing has ever been brought up or discussed? Do you know if anything (technically) would prevent implementing this in C# / dotnet, or in a code generator?

[333fred]

It has never been discussed to my knowledge.

Do you know if anything (technically) would prevent implementing this in C#

Yes, this would be pretty challenging to implement. In order to work, Delegate<TReturn> would have to be a supertype of Func<TModel, TReturn>. That would be a pretty big change, particularly if we then want to allow the inverse (Delegate<TModel>).

[mycroes]

It's only about the return, so Func<TModel, TRet> is only Delegate<TRet>. I guess the inverse could be pretty cool as well, but explicit return types would already float my boat.

Of course every non-void delegate would need to extend Delegate<TRet> and Delegate<TRet> will extend Delegate, so I guess nothing is lost and such a change would be backwards compatible. You're saying it sounds challenging, but is there anything challenging about these requirements?

Would this be a good fit for a language proposal? I don't mind investing some time into this and I think it's a really valuable feature, considering above cases are pretty common struggles from what I've seen.

[mycroes]

I've noticed C# isn't really eager to resolve the types if you throw in nested lambdas. However, with some help, you can hint it and work around most issues. Instead of having Delegate<TResult> I opted to use Func<TServices, TResult> for now, where I'll add a transform to permit value tuples for TServices, thus working around all of the unknown type issues.

The solution using above workarounds:

internal class Factory
{
    public static Configuration<TResource, TModel> CreateConfiguration<TResource, TModel>(Func<TResource, TModel> projection)
    {
        throw new NotImplementedException();
    }

    public static Configuration<TResource, TModel> CreateConfiguration<TResource, TModel, TServices>(
        Func<TServices, Expression<Func<TResource, TModel>>> projectionFactory)
    {
        throw new NotImplementedException();
    }

    public static Configuration<TResource, TModel> CreateConfiguration<TResource, TModel, TServices>(
        Func<TServices, Task<Expression<Func<TResource, TModel>>>> asyncProjectionFactory)
    {
        throw new NotImplementedException();
    }
}

internal class Configuration<TResource, TModel>
{
    public void Create(Func<TModel, TResource> handler)
    {
        throw new NotImplementedException();
    }

    public void Create<TServices>(Func<TModel, TServices, TResource> handler)
    {
        throw new NotImplementedException();
    }

    public void Create<TServices>(Func<TModel, TServices, Task<TResource>> asyncHandler)
    {
        throw new NotImplementedException();
    }
}

How to use these:

internal record Input(int Id, string Name, bool Whatever);

internal static class Identity
{
    /// <summary>
    /// Hint the compiler that the argument is an <see cref="Expression"/>.
    /// </summary>
    /// <typeparam name="T">The expression type.</typeparam>
    /// <param name="expression">The expression to return.</param>
    /// <returns><paramref name="expression"/>.</returns>
    public static T Expression<T>(T expression) where T : Expression => expression;
}

Creating a configuration with a model projection:

// No services
var config = Factory.CreateConfiguration((Input i) => new { i.Id, i.Name });

// Single service
var config = Factory.CreateConfiguration((DbContext db) =>
    Identity.Expression((Input i) => new { i.Id, i.Name, Batch = db.Set<object>().First() }));

// Multiple services, sync
var config = Factory.CreateConfiguration(((DbContext db, HttpContext httpContext) services) =>
    Identity.Expression((Input i) => new { i.Id, i.Name, Batch = services.db.Set<object>().First() }));

// Multiple services, async
var config = Factory.CreateConfiguration(async ((DbContext db, HttpContext httpContext) services) =>
{
    await Task.Delay(1000);

    // Compiler can't resolve the lambda to target expression without a bit of help
    return Identity.Expression((Input i) => new { i.Id, i.Name, Batch = services.db.Set<object>().First() });
});

Setting the create handler:

// No services
config.Create(model => new Input(model.Id, model.Name, false);

// Multiple services, sync
config.Create<(DbContext db, HttpContext httpContext)>((model, services) => new Input(model.Id, model.Name, true));

// Multiple services, async
config.Create<(DbContext db, HttpContext httpContext)>(async (model, services) =>
{
    await services.db.Set<object>.AnyAsync();
    return new Input(model.Id, model.Name, true);
});

This might actually be slightly improved when #258 is implemented and the tuple elements can be deconstructed directly in the delegates.

This still doesn't affect the benefits of Delegate<TResult> though, I'd very much prefer that over Func<TArgs, TResult>, but for now it's something I can work with.