I've just realized that reflection still not recognizes these constructors (e.g. new ReflectionMethod("ZipArchive", "__construct");) results in an exception).

I think this should be addressed in PHP 8.3 so that each class has to either declare or inherit a constructor (this would only be enforced by gen_stub.php). PHP 8.2 could still emulate the default constructors as per this PR. What do you think?

I've just realized that reflection still not recognizes these constructors (e.g. new ReflectionMethod("ZipArchive", "__construct");) results in an exception).

I think this should be addressed in PHP 8.3 so that each class has to either declare or inherit a constructor (this would only be enforced by gen_stub.php). PHP 8.2 could still emulate the default constructors as per this PR. What do you think?

I'm not sure, it makes sense because the main reason why a constructor is not implemented is that it doesn't take any argument, because it is pointless. And documenting it when it doesn't exist seems like a mistake in the same way as changing the internal behaviour because you can hit this exact same issue in userland: https://3v4l.org/mOTEF

I've just realized that reflection still not recognizes these constructors (e.g. new ReflectionMethod("ZipArchive", "__construct");) results in an exception).

Hmm, this is an issue. If we document ::__construct(), but there is none, that is at least confusing for users. At the very least, we would need to document that these methods do not really exist, but it would probably be better to not document them. Maybe some other tool could help us to find which of the currently documented constructors don't actually exist (might be very hard wrt. PECL/extensions, though)?

Hmm, this is an issue. If we document ::__construct(), but there is none, that is at least confusing for users. At the very least, we would need to document that these methods do not really exist, but it would probably be better to not document them.

I disagree with the "they do not really exist" and the "it would probably be better to not document them" parts: all classes have at least the default constructor which doesn't take any arguments and which doesn't do anything (apart from instantiating the class). That's why it makes sense to document them in my opinion (even the ones which result in an exception to clarify that they shouldn't be used).

What reflection really provides information about is whether a class has (declares or inherits) a custom constructor implementation. I agree that it's debatable to change this, but any way, from a user perspective, constructors can be invoked on any classes, no matter what reflection says.

you can hit this exact same issue in userland

Yeah, I forgot to mention this in my previous reply, but the above point stays. :)

all classes have at least the default constructor

I don't think this ("default constructor") is a valid model for PHP (contrary to some other languages). Instead we should distinguish between object creation and construction (i.e. calling the constructor). While the PHP manual doesn't seem to be particularly clear on this, the language specification is:

The object is then initialized by calling the class's constructor passing it the optional argument-expression-list. If the class has no constructor, the constructor that class inherits (if any) is used. The class can also specify no constructor definition, in this case the constructor call is omitted.

Ignoring reflection (or reflection like features), and while it is generally not recommended to explicitly call the constructor, that is possible, but only if a __construct() method has been defined (or inherited): https://3v4l.org/VC2n6

Of course, one may argue that there is a default constructor (if not explicitly defined or inherited) which is called, but can't be called explicitly and is not "visible" to reflection, but in my opinion, this complicates what is actually going on, and as such is not a helpful model for userland developers (it is more complex for internals due to .get_constructor() and the "ctor" naming, but I'd rather "shield" userland developers from this).

Ignoring reflection (or reflection like features), and while it is generally not recommended to explicitly call the constructor, that is possible, but only if a __construct() method has been defined (or inherited): https://3v4l.org/VC2n6

Thank you for highlighting this fact, I completely forgot to check it (even though I did check other magic methods...). You persuaded me that documenting non-existent constructors is a wrong approach, so I did a few followups:

• from now on, gen_stub.php doesn't want to display "default" constructors
• I submitted a PR to revert my recent default constructor additions to the manual (Revert "Add documentation for default constructors - part 1 (#2089)" doc-en#2121)
• I submitted a PR to remove the documentation for any non-existent constructors (Remove unnecessary documentation of non-existent constructors doc-en#2122)