[Proposal]: allow the keyword interface as generic constraint

[BrayanKhosravian]

allow the keyword interface as generic constraint

• Proposed
• Prototype: Not Started
• Implementation: Not Started
• Specification: Not Started

Summary

This feature would allow restricting generic parameters for any interface.

Motivation

The motivation is to make generic constraints more flexible and restrictive.

With the given proposal the caller could specify any interface instead of a specific one.
And the caller is restricted not to specify a class or a struct.

Detailed design

the following code does not compile:

public void RegisterService<TService, TInterface>()
	where TService : class
	where TInterface : interface // <- CS1031 "type expected"
{
	_containerBuilder.RegisterType<TService>().As<TInterface>();
}

Drawbacks

Alternatives

1.) A possible workaround would be to create a "markup interface" which is empty and use it for the constraint.
But this means that all interfaces have to implement that "markup interface".

2.) Not to restrict for only interfaces and use class as a constraint

Unresolved questions

Design meetings

[svick]

The motivation is to make generic constraints more flexible and restrictive.

That's not really a motivation. Why do you think such constraint would be useful?

[BrayanKhosravian]

With the given proposal the caller could specify any interface instead of a specific one.
And the caller is restricted not to specify a class or a struct.

Will update the proposal.

[svick]

@BrayanKhosravian That still only describes what the proposal is, but not why should it be added to the language.

[333fred]

I'm going to move this to be a discussion. I'm also not convinced why this needs to be a constraint, and I think some discussion around the topic would be better before making this a full proposal. What issue are you trying to solve? What code does this enable that wasn't possible before? Motivating examples are very helpful for trying to understand why you want to see this feature in C#.

[JustNrik]

interface constraint was suggested before and it didn't go well #3682

What exactly is the point of restricting a generic argument to an interface specifically?

You can't use that as a common abstraction, as interfaces by themselves have no API surface, and you cannot instantiate them, which means any object you can pass into them would fail such constraints. It's a proposal that defeats itself.

[scottdorman]

I'm not seeing the scenario here that makes this a feature that's needed? The class constraint implies that the type must be an object type, while the new() constraint says it must have a public parameterless constructor, and so on. Those are necessary to both restrict that set of types that can be used and also information for emthid access. By saying the type must be constrained to any arbitrary interface doesn't give any of that information.

The language team can't implement a feature if they don't know what that feature is supposed to do and have scenarios around what it will enable (or what it prevents).

As for the referenced prior proposal, after having read through it, it didn't go well because there were no explanations of what the feature meant to achieve and the entire tone was combative (at least, that's how I interpreted it).

[Joe4evr]

*wink wink, nudge nudge*

[dstarkowski]

Seems like a great use case for analyzers. Generic constraints are not to limit, but enable more functionality.

[BrayanKhosravian]

Thanks for all the responses.
I didnt know that a similar proposal was already posted before, even after a quick search.
And I only read some parts of that proposal.

Here is a concrete example about why I think this could be useful. Ofc this is not a must-have feature but it would be nice.
But when this is not worth the effort it is fine for me to close this proposal/discussion.

interface IService
{
	void Execute();
}

class Service : IService
{
	public void Execute() => throw new NotImplementedException();
}

class IoC
{
	private readonly ContainerBuilder _containerBuilder = new ContainerBuilder();
	public void RegisterService<TService, TInterface>()
		where TService : class
		where TInterface : class 
	{
		if(!typeof(TInterface).IsInterface) throw new ArgumentException($"{nameof(TInterface)} has to be an interface!");

		_containerBuilder.RegisterType<TService>().As<TInterface>();
	}
}

class Program
{
	public static void Main()
	{
		var ioc = new IoC();
		ioc.RegisterService<Service, IService>(); // <- this method should be used like this
		ioc.RegisterService<Service, Service>();  // <- i dont get a warning or error here at design time but im throwing an 
                                                                                // exception at runtime
	}
}

[Joe4evr]

Minor nits:

• It'd read slightly better if the order of your type parameters was <TInterface, TService> (this is also the pattern used by MS.Ex.DI)
• You should also constrain TService : TInterface

[CyrusNajmabadi]

Your use case here can be easily solved given an analyzer that is supplied with that library. You can also then take that analyzer as far as you want. I.e. if there are checks beyond that, you can easily add without the language needing to change

[Joe4evr]

Which is exactly why I've made an analyzer package for enforcing this scenario, enforcing a type be non-abstract (the very useful counterpart to this), and even one for CRTP. :P

[BrayanKhosravian]

Ty for mentioning that I should add the constraint. That makes sense.
I did now know that this can be solved with analyzers as I never wrote some.
Thank you all so for.

This can be closed from my side.