I suggest we replace this Protocol with simply Callable[P, T_co]; I didn't realize at the time that Callable fulfills the criteria for capturing init args and return type :)

Right, I suppose that works too; it would widen the possible input types though, since it allows arbitrary callables and isn't necessarily limited to types. Something like Callable[P, T_co] & Type[T_co] would be cool, if we had intersection types.

it would widen the possible input types

I'm aware, however I don't see a reason to restrict the accepted types. The runtime already supports that if not for the issubclass checks, this would work out of the box.

I've gone and loosened the cls type requirement in 42a5edb, and removed the runtime check in 6a4aafb.

While passing a function to a parameter named cls doesn't really make sense semantically, you're right that there also isn't really a reason to artificially restrict this as much. If someone is using custom view decorators, I would assume they already know what they're doing :>

That said, I'm not quite sure if/how this should be documented without introducing more confusion, or if we should leave the documentation as cls: Type[...] for now.-

See, this is where cls being pos-only would come useful :kek:
With the new semantics, factory would be a better name, and I think at least the docs could be updated to treat it as so.