Implicitly nullable parameters are deprecated

[remco-pc]

Description

The following code:

<?php
 echo 'create entity2 class' . PHP_EOL;    
d(Database::config($object));                                    
echo 'strange' . PHP_EOL;
d(Build::entity(
$object, 
$options['class'], 
$options['role'], 
$options['node']
));
echo 'stranger' . PHP_EOL;

Resulted in this output:

create entity2 class
/Application/Mount/Shared/Event/Raxon/Doctrine/Schema.php:116
object(Doctrine\ORM\Configuration)#2494 (7) {
 ...
}
strange

But I expected this output instead:

create entity2 class
/Application/Mount/Shared/Event/Raxon/Doctrine/Schema.php:116
object(Doctrine\ORM\Configuration)#2494 (7) {
 ...
}
strange
stranger;

It seems that i had another function in Build with some parameters which where deprecated in php 8.4 "Implicitly nullable parameters are deprecated"

When i fix that error, it works again.

I don't get a warning in the terminal (the deprecations), it just stops executing at that call build. My error reporting is like that every error becomes an exception it would be echoed but it doesn't.

Why is this even a thing and make nullable explicit at both sides of the variable object|null $connection=null?

PHP Version

PHP 8.4.10 (cli) (built: Jul  3 2025 12:45:15) (NTS)
Copyright (c) The PHP Group
Built by Debian
Zend Engine v4.4.10, Copyright (c) Zend Technologies
    with Zend OPcache v8.4.10, Copyright (c), by Zend Technologies

Operating System

Debian 12

[iluuu1994]

As mentioned previously, we need a fully reproducible example to help you. ¹ Maybe you have an error handler installed that terminates, it's impossible to tell just from looking at your example.

Why is this even a thing and make nullable explicit at both sides of the variable object|null $connection=null?

The short answer is because it was voted on. ² If you're unhappy about this, that's a discussion to be held on the internals mailing list. ³

Footnotes

1. https://www.sscce.org/ ↩

2. https://wiki.php.net/rfc/deprecate-implicitly-nullable-types ↩

3. https://www.php.net/mailing-lists.php ↩

[remco-pc]

@iluuu1994 a fully reproducable example would include an autoloader. It happens when the class gets loaded through the autoloader class.

I've indeed a catch all exception and error handler defined and have had these deprecation warnings all over the place which are hard to detect (need to search on =null in every class).
In the same time of deprecating this stuff you could have made an implicit condition if =null then add |null but not when mixed... which is less work for everybody and i still probably need a detector for it because i missed at least one of them which causes a die without exception in this case.

I just disagree on this one, because the solution is a simple detect and adjust under the hood which makes the parameters better readable instead of rust style parameter hell.

[iluuu1994]

a fully reproducable example would include an autoloader.

Possibly not if you break down the reproducer. But if it requires an autoloader, then that's fine too. What we can't do is diagnose an issue in code that we can't see.

I've indeed a catch all exception and error handler defined and have had these deprecation warnings all over the place which are hard to detect (need to search on =null in every class).

Maybe the error handler does something weird. Try disabling it and see what happens. Maybe it throws an exception, and then your exception handler swallows the top-level exception.

In the same time of deprecating this stuff you could have made an implicit condition if =null then add |null

That's already how it worked for years. I don't necessarily agree with this change, but it has been decided by the community so discussing it here is futile.