[Proposal]: Extend Generic new() constraints

[crone66]

Lets assume the following interfaces and classes

interface IUser<TKey>
    where TKey : IEquatable<TKey>, new()
{
    Tkey Id { get; set; }
}

class User : IUser<Guid>
{
    Guid Id { get; set; }
    public User (Guid id)
    {
      //assignment
    }
}

interface IRole<TKey>
{    
    TKey Id { get; set; }
    string RoleName { get; set; }
}


class Role : IRole<Guid>
{   
    Guid Id { get; set; }
    string RoleName { get; set; }

    public Role(Guid id, string roleName)
    {
      //assignment
    }
}

class XYZService<TUser, TRole, TKey>
    where TUser : IdentityUser<TKey>, IUser<TKey>, new()
    where TRole : IdentityRole<TKey>, IRole, new()
    where TKey : IEquatable<TKey>
{
    void Method(TKey key,  TKey roleKey, string roleName)
    {
        var user = new TUser();
        user.Id = key;
        var role = new TRole();
        role.Id = roleKey;
        role.RoleName = roleName;
    }
}

It would be nice to allow construct type constraints such as the following.

    where TUser : IdentityUser<TKey>, IUser<TKey>, new(TKey)
    where TRole : IdentityRole<TKey>, new(TKey, string)

Full code:

class XYZService<TUser, TRole, TKey>
    where TUser : IdentityUser<TKey>, IUser<TKey>, new(TKey)
    where TRole : IdentityRole<TKey>, new(TKey, string)
    where TKey : IEquatable<TKey>
{
    void Method(TKey key, TKey roleKey, string roleName)
    {
        var user = new TUser(key);
        var role = new TRole(roleKey, roleName);
    }
}

TKey could for example be a Guid and for TRole I want to have a constructor that takes for example an id and a role name or even more parameters. It's cleaner, less code and I don't have to make the Property setter internal or public.

With the "relativly" new static interface members the following workaround archives essentially the same which means It probably can be added "simply" by using source code generation.

interface IFactory<TType, TArg, TArg2>
{
    static abstract TType Create(TArg);
    static abstract TType Create(TArg, TArg2);
}

class XYZService<TUser, TRole, TKey>
    where TUser : IdentityUser<TKey>, IUser<TKey>, IFactory<TUser, TKey>
    where TRole : IdentityRole<TKey>, IFactory<TRole, TKey, string>
    where TKey : IEquatable<TKey>
{
    void Method(TKey key, TKey roleKey, string roleName)
    {
        var user = TUser.Create(key);
        var role = TRole.Create(roleKey, roleName);
    }
}

Sorry in case it's a duplicate but I couldn't find a similar discussion.
What do you think?

[BreyerW]

exactly because theres already a workaround you mentioned this idea isnt going to gain any traction. Additionally theres plan to make it possible to add ad hoc interfaces via extensions (or more specifically 'roles') and if this will work for static abstract then you will be able to add them to types you dont own and make them eligible for generics expecting Create like methods which is the only larger scenario thats missing AFAIK rn, compared to feature you mentioned (since i assume u want it to work for types u dont own too)

[crone66]

new() feels just like an half finished solution right now.

[crone66]

and based on the many dupes provided by ufcpp below it seems like a highly requested feature. Therefore, I don't see a point not to add it if it's requested that often.

[HaloFour]

The bigger issue is that without some kind of runtime changes there really isn't support to describe this constraint in metadata. C# could do something custom like F# did, but that means that other languages can ignore the constraint and call the method with incorrect type arguments and the runtime won't do anything to prevent that.

[crone66]

not necessarily like other keywords it could be possible by taking advantage of source code generation.

[franchyd]

I think that in the context of evaluating language features runtime changes should be evaluated as an additional cost but not an "issue" because the runtime can be changed the questions is whether or not it's worth it. It's not as if the runtime team would reject a request from the language team without consideration.

[ufcpp]

dup of #8542
Many many dups: #8542 (comment)