Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88795
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.48 as permitted sender)
To: Andrea Faulds <ajf@ajf.me>, internals@lists.php.net
References: <0A.C2.33697.6AECE165@pb1.pair.com> <561ED07E.4060809@gmail.com>
 <561ED5D3.1070500@ajf.me>
Message-ID: <561EDA7C.1070609@gmail.com>
Date: Wed, 14 Oct 2015 15:43:08 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0)
 Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <561ED5D3.1070500@ajf.me>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: =?UTF-8?Q?Re:_[PHP-DEV]_[RFC]_Void_Return_Type_=28v0.2=2c_re=c3=b6p?=
 =?UTF-8?Q?ening=29?=
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> And, heck, we use void in the PHP manual all the time.

Yes, because PHP manual *is* the documentation :) Note that function
descriptions in the manual, while they are similar to PHP syntax, aren't
actually valid PHP, even after scalar typing introduction. Bizarrely
enough, they don't even match the return type syntax.

> It most likely is, but it's not the only case that matters. What if you
> mistakenly return a value in a function that's not supposed to? This
> would catch you out.

Why would I care about such a mistake? Why would I care so much that I
would need a special language-level construct to catch it? How many such
mistakes happen and are they critical enough to have the engine
bothering with going after them? I think such mistakes are extremely
rare and insignificant.

> I feel that the basic facts about a function should be in the signature,
> and shouldn't have to be hidden in a comment, if only because it's more

I guess we disagree here, because I do not think comments are "hidden",
and I do not think signature of the function should be the comment. In
fact, in Java for example (which seems to be the model language for the
strict typing aficionados) it is long standing best practice to actually
verify the javadoc comments as part of the build and fail the build if
they are missing or wrong. I am not advocating for doing (or not doing
:) this in PHP, but I do say documentation is not "hidden" and strict
typing is not the same as documentation. Moreover, in this case strict
typing implies something that is outright false - the function that is
declared void does return a value, namely null. Even worse, if you do
try to return exactly the same value, the RFC requires failure in this
case, which makes zero sense as precisely the same thing happens in both
cases.

> concicse and keeps information about parameters on the same line as the
> parameters themselves. Unlike comments, type hints can't lie, because
> they're actually enforced.

In fact, it is the opposite - as I said above, that particular type does
lie, and it has to, because what it tries to express actually does not
exist in PHP.
I might be reluctantly ok with tolerating purely documentation type, but
tolerating purely documentation type that is in fact untrue does not
look good to me.
-- 
Stas Malyshev
smalyshev@gmail.com