Doc #76311 [Ver]: __construct/destruct/clone do not have return types

From: Date: Tue, 08 May 2018 20:55:14 +0000
Subject: Doc #76311 [Ver]: __construct/destruct/clone do not have return types
References: 1  Groups: php.doc.bugs 
Request: Send a blank email to doc-bugs+get-15666@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=76311&edit=1 ID: 76311 Updated by: cmb@php.net Reported by: Andy_Schmidt at HM-Software dot com Summary: __construct/destruct/clone do not have return types Status: Verified Type: Documentation Problem Package: Class/Object related PHP Version: 7.2.5 Block user comment: N Private report: N New Comment: > I can't tell what ambiguity they're talking about, but I suspect > it doesn't apply to PHP since return types are invariant. It seems to me this “ambiguity” is actually what this discussion is about: if no return type annotation/declaration would be given, should return statements be checked, or not? In my opinion, it does not make much sense, though, to make a constructor special so that only a None/void return type annotation/declaration would be accepted, rather than to make a constructor special by not allowing to specify any return type annotation/declaration, in the first place. FWIW: JavaScript's constructor functions are a notable exception to the no return type, since new Foo may return a Bar. Anyhow, I don't think it is useful to have a lengthy discussion here; the internals mailing list would be more suitable. Previous Comments: ------------------------------------------------------------------------ [2018-05-08 17:27:51] requinix@php.net > using a syntax that resembles that of normal methods is besides the point. Hmm, okay, poor choice of words there, but what I'm trying to say is that for these three methods return types do not make sense. Because there are no return values. Not in the sense of "this function isn't returning a value" but more "this function is incapable of using return values in the first place". Other languages: C# and Java don't have types. > class Example { public Example() { } } Python 3 does support a return type on __init__ but for reasons I don't quite understand. https://www.python.org/dev/peps/pep-0484/#id13 > (Note that the return type of __init__ ought to be annotated with -> None. The reason for > this is subtle. If > __init__ assumed a return annotation of -> None, would that mean that an argument-less, > un-annotated __init__ method > should still be type-checked? Rather than leaving this ambiguous or introducing an exception to > the exception, we > simply say that __init__ ought to have a return annotation; the default behavior is thus the > same as for other > methods.) I can't tell what ambiguity they're talking about, but I suspect it doesn't apply to PHP since return types are invariant. (There's also __new__ but that's more of a factory method than a constructor.) Meanwhile Ruby has constructors but no return types, and Perl has return types but no constructors. ------------------------------------------------------------------------ [2018-05-08 17:08:08] requinix@php.net https://www.google.com/search?q=why+dont+constructors+have+return+types This isn't about method signatures. This is about what constructors, destructors, and cloning represent. The fact that PHP allows you to specify their behavior using a syntax that resembles that of normal methods is besides the point. ------------------------------------------------------------------------ [2018-05-08 17:05:14] Andy_Schmidt at HM-Software dot com I understand that some methods had always implicitly disallowed return values before there had been a syntax to do so explicitly. The hard syntax error certainly was proper before 7.1. However, this is 2018. Why would we still force occasional PHP users from having to memorize the signature for each and every magic method? Now that "void" is a type hint, it seems that an author writing self-documenting code (for the benefit of less-versed coworkers) should not be penalized with run-time errors for explicitly defining VOID? I respectfully suggest that with 7.1 and higher, the message category "... cannot declare a return type" should simply recognize the now-available type "void" as being a perfectly expression of the implicit rule! ------------------------------------------------------------------------ [2018-05-08 16:49:06] requinix@php.net Related To: Bug #76312 ------------------------------------------------------------------------ [2018-05-08 16:47:16] requinix@php.net True, but __wakeup allows for a void return type. Which I don't mind because its counterpart __sleep does have a return type. To me it's more the fact that __construct/destruct are particularly special methods and explicitly disallow return types. __clone too, now that I look at the list. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=76311 -- Edit this bug report at https://bugs.php.net/bug.php?id=76311&edit=1

« previous php.doc.bugs (#15666) next »