IServiceProvider.GetServices return value nullability

[WeihanLi]

Currently, the API return value type is IEnumerable<object?> while the API implementation is returning IEnumerable<object>

see

https://github.com/dotnet/runtime/blob/b4823d05c38d7eb44de0db41ba9ba6c6a2df4e46/src/libraries/Microsoft.Extensions.DependencyInjection.Abstractions/src/ServiceProviderServiceExtensions.cs#L88-L95

so should we update the API return value type to IEnumerable<object> to align with the method return value type?

namespace Microsoft.Extensions.DependencyInjection;

public static class ServiceProviderServiceExtensions
{
-    public static IEnumerable<object?> GetServices(this IServiceProvider provider, Type serviceType);
+    public static IEnumerable<object> GetServices(this IServiceProvider provider, Type serviceType);
}

[ghost]

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

Issue Details

---

Currently, the API return value type is `IEnumerable` while the API implementation is returning `IEnumerable

[stephentoub]

I don't see anything in the implementation guaranteeing the objects aren't null. Non-nullability isn't part of the runtime type identity. It'd be ok to change the cast to IEnumerable<object?>, but I don't see anything here that would allow us to change the method return type to IEnumerable<object>.

[WeihanLi]

Then should public static System.Collections.Generic.IEnumerable<T> GetServices<T>(this System.IServiceProvider provider) return IEnumerable<T?>?

https://github.com/dotnet/runtime/blob/b4823d05c38d7eb44de0db41ba9ba6c6a2df4e46/src/libraries/Microsoft.Extensions.DependencyInjection.Abstractions/ref/Microsoft.Extensions.DependencyInjection.Abstractions.cs#L233

Generally, think we would not register a null for the service, but indeed, it could be injected now

var services = new ServiceCollection();
services.AddSingleton<IService>(sp => null!);

[stephentoub]

@halter73, is there anything preventing a null instance from being registered / returned? If not, should there be?

[halter73]

As @WeihanLi pointed out, you can register a factory that returns null. I don't think it's very common, but I'm sure people have done it. I'm sure it's even less common to both register null-returning factory and also call GetServices(Type) with the corresponding service type. I've never seen it, but it is possible.

I definitely prefer IEnumerable<object> over IEnumerable<object?> for the GetServices() return type, but I understand not wanting to do that if null could ever end up there even in the rarest circumstances. I see two options for making this non-nullable without lying.

1. We do a null check every time we ever call a factory and add notnull constraints as appropriate on TImplementation and/or TService for methods that register factories (or perhaps all the service registrations). This would be how I'd do it if I were starting from scratch, but it would definitely be the most breaking option.
2. Filter out null from the IEnumerable<object> if it is present. This is definitely the weirder behavior, but it's less unlikely anyone would ever hit this case which makes it less likely to break people.

[buyaa-n]

Added api-suggestion label as it is about public API shape, feel free to mark as api-ready-for-review and/or update the mileston as needed.