Re: [VOTE] Void Return Type RFC

From: Date: Thu, 29 Oct 2015 18:33:44 +0000
Subject: Re: [VOTE] Void Return Type RFC
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-89005@lists.php.net to get a copy of this message
Hi Stas, Stanislav Malyshev wrote:
Hi!
type (or pseudo-type) to do this. We should add null as a return type rather than void as null:
I don't think we should do either. The whole story bases on the premise that it is very important to avoid functions that accidentally return non-null value. I do not think this premise is valid - in fact, I think overall number of errors caused by this is so small that we already spent collectively more time on discussing this than would be ever saved over lifetime of PHP by introduction of this check. The only practical (in a wide sense of the word) use of the void/null type there would be making PHP functions more like ones in other languages, where you can (actually, in most cases, must) declare functions void, so we obviously need to have that too. In my book, this is not a very necessary thing.
There is a quite important use-case I've been informed of (alas I cannot recall who by), and it was one of the things that motivated me to revive the RFC. For interfaces, it's important to be strict in your definitions, so you don't end up with implementation-defined behaviour that people accidentally rely on. One of the problems that crops up is that you can't currently specify that an interface method doesn't return anything. This means that implementations sometimes add return values, and functions get written that rely, unintentionally, on objects with that interface having that behavioury. With the void type, implementations of an interface are forbidden from returning a return value, so this issue goes away. Thanks. -- Andrea Faulds http://ajf.me/

« previous php.internals (#89005) next »