Can you describe a bit more the use case?

@dunglas this can be useful when you use a third party library allowing to instantiate its classes with static methods (even if this proposal looks risky to me and i would prefer to be able to customize the object factory).

IMO it would be easier to use a custom normalizer for that kind of usage.

@dunglas I agree even if i think we should allow to simply override the class constructor with something like:

protected function getConstructor(string $class, \ReflectionClass $reflectionClass) : \ReflectionMethod
{
    return $reflection->getConstructor();
}

protected function instantiateObject(/** ... */)
{
    // ...
    $constructor = $this->getConstructor($class, $reflectionClass);
    // ...
    if ($constructor->isConstructor()) {
        return $reflectionClass->newInstanceWithArgs($args);
    } else {
        return $constructor->invokeArgs(null, $args);
    }
}

WDYT ?

@l3l0 would also be able to fix his issue without introducing a hack in the core.

@Ener-Getick Good idea!

@dunglas @Ener-Getick use case is quite simple... serialize and unserialize events with private constructor (cause events have many named constructor) and I do not want to break encapsulation and make constructor public only because serializer do not handle that :) This can be the problem with serializing other kind of Value Objects as well.
I resolved my issue by writing custom normalizer for now.

Extension point proposed by @Ener-Getick seems to make such changes easier and it seems like good idea (I would even thiking about delegating instantiateObject to separate object/class).

We should consider change default behavior of property normalizer as well, cause it seems strange to me that data are read/write by reflection and calling constructor is required (or at least it should be optional)

@l3l0 i don't think this is worth creating a new class. At worst, we can allow to pass a callable to the normalizer as what is done to manage circular references but i think the right way is just to extend the normalizer.

I like @Ener-Getick proposal more than the current implementation of this PR.

I opened #19137.