Should IStringLocalizer be covariant?

Like ILogger<T>, IOptions<T> or IOptionsMonitor<T>, should IStringLocalizer<T> be covariant? This would allow this kind of pattern:

public class Base
{
    public Base(IStringLocalizer<Base> localizer) { }
}

public class Derived : Base
{
    public Base(IStringLocalizer<Derived> localizer)
        : base(localizer) { }
}

[kevinchalet]

Excellent, I’ll send a PR soon, then 😄

[kevinchalet]

Do you have something concrete @PinpointTownes ?

Yeah, the main scenario I have in mind is to allow an application to override the resources location when subclassing a class from a class library that comes with .resx files and uses [assembly: ResourceLocation("...")].

// Defined in a class library.
public class Base
{
    // Uses the resources defined in the class library (ClassLibrary.Resources.Base).
    public Base(IStringLocalizer<Base> localizer) { }
}

// Subclassed in application code.
public class Derived : Base
{
    // Uses the resources defined in the application (App.Resources.Derived).
    // Both this class and the base one will use the application strings.
    public Base(IStringLocalizer<Derived> localizer)
        : base(localizer) { }
}

It’s exactly like how options and generic loggers work:

public class Base
{
    public Base(IOptions<Base> options) { }
}

public class Derived : Base
{
    // Resolve specialized Derived options and inject them
    // into the base class as IOptions<Base>.
    public Base(IOptions<Derived> options)
        : base(options) { }
}

It’s something I use in OpenIddict: I have a OpenIddictServerOptions class that inherits from OpenIdConnectServerOptions (from ASOS) and defines additional options. Wherever IOptionsMonitor<OpenIdConnectServerOptions> is used, I simply flow IOptionsMonitor<OpenIddictServerOptions> (e.g https://github.com/openiddict/openiddict-core/blob/dev/src/OpenIddict.Server/OpenIddictServerHandler.cs#L25).