Invalid type 'Nette\DI\?T' when accessing `Container#getByType()` from DI config

[dakur]

Version: 3.0.11, bug present as of 3.0.10

Bug Description

If you use Container#getByType() inside of NEON configuration, it fails on resolving its return type – from Helpers#getReturnTypeAnnotation() it is returned Nette\DI\?T.

More generally, I believe (have not tried) accessing any class with method having generic return type will fail.

Steps To Reproduce

In nette/web-project, create this class:

namespace App;
final class FakeContainer
{
	/**
	 * copied from Container#getByType()
	 * @template T
	 * @param class-string<T> $type
	 * @return ?T
	 */
	public function getService(string $type)
	{
		return null;
	}
}

In services.neon, use it:

services:
	- App\FakeContainer::getService(HomepagePresenter::class)

Expected Behavior

Run, not to fail with type check.

[dakur]

Note that if you change @return ?T to @return T, it fails with different error. I think that is related.

[milo]

What if you declare it as following?

public function getService(string $type): object
{}

[dakur]

That doesn't seem to help..

Return type of App\FakeContainer::getService() is not expected to be nullable/union/intersection/built-in, 'object' given

[JanTvrdik]

This seems like expected behavior, generics are not supported.

[dg]

DI doesn't support generics and I don't plan to implement it, in fact I plan to remove support for @return annotation completely in version 4. But you can specify the type directly in the config:

services:
	- factory: App\FakeContainer::getService(HomepagePresenter::class)
	  type: HomepagePresenter

[mabar]

Is there any reason to not support object?

[dg]

It is always object.

[mabar]

I mean it's bit confusing from the user's point of view that object is not allowed return type of method. But in reality it's okay and we just have to declare more specific type in neon because library is not able to infer it from generics itself. Some hint like "I don't understand object / Foo&Bar / ... type, could you change the type to some specific class or add the type to service definition?" would be helpful

[dg]

It's not that it doesn't understand it, it understands and doesn't allow it. So return type is not expected to be nullable/union/intersection/built-in type.

[dakur]

@dg Thank you, but the suggestion did not help for the example code – it fails with Return type of App\FakeContainer::getService() is not expected to be nullable/union/intersection/built-in, 'object' given Invalid App\?T* (sorry, the long message was for forced object return type)

It didn't help in real code either as I already have type already set there. So maybe there is also bug in type not making any effect?

For illustration, I attach real code:

pages.filesystem:
	type: League\Flysystem\Filesystem
	factory: @outerContainer::getByType(PageFilesystemProvider)::getPageFilesystem()
	autowired: false

Just an explanation of our use-case: we have app and model container – app is outer, model inner. App can use services from inner (model) container, but model container needs some bindings to the app world – e.g. translator, identity etc. – thus this @outerContainer::getByType() calls.

I understand that such usage of DI can be a bit marginal/edge-case (🤷‍♂️❓), but I still think it reveals some bug(s) in DI resolver/type checking.

---

* The message actually changed from Nette\DI\ServiceCreationException: Service (App\FakeContainer::getService()): Invalid type 'App\?T' (reported in the original post) to Nette\InvalidArgumentException: Invalid type 'App\?T' so it must failed at different place.

[dg]

Yeah, I finally get it, the problem is the throwing of the exception.

So it should work that if the return type is 'object', it will ignore the @return annotation and 'object' too, right?

[dakur]

So it should work that if the return type is 'object', it will ignore the @return annotation and 'object' too, right?

Not pretty sure. I don't have such knowledge of DI to tell if this is solution to the root cause, sorry. I'm not even sure I know what is the root cause actually.

But yeah, the problem is that it throws exception instead of returning HomepagePresenter/PageFilesystemProvider instance.

[dg]

Try v3.0-dev, now is should work.

final class FakeContainer
{
	/**
	 * @template T
	 * @param class-string<T> $type
	 * @return ?T             
	 */
	public function getService(string $type): ?object  // @return ?T is ignored now
	{
	}
}