Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84001
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain seld.be designates 74.125.82.173 as permitted sender)
Message-ID: <54F074D1.8000403@seld.be>
Date: Fri, 27 Feb 2015 13:44:49 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CACouGvmRKX+qrexHfoW-9k0E9vW-ZPkRc6oz0vZ1g9CH7krQMQ@mail.gmail.com>
In-Reply-To: <CACouGvmRKX+qrexHfoW-9k0E9vW-ZPkRc6oz0vZ1g9CH7krQMQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Follow-up to STH user experience, this time with actual
 testing
From: j.boggiano@seld.be (Jordi Boggiano)

Matthew,

Thanks a bunch for going through this and writing such a detailed report.

On 27/02/2015 00:29, Matthew Weier O'Phinney wrote:
> ### STHv5
>
[snip]
> #### Analysis
>
> I did not expect the float value to be coerced, particularly as it had a
> fractional part. Yes, I understand that this is how casting _currently_ works in
> PHP, and that the patch uses the current casting rules. However, I'd expect that
> any float with a fractional value would not be cast to an integer; doing so is
> lossy, and can lead to unexpected results.
>
> The strict_types mode operated how I would expect it, but meant I was forced to
> add the declaration to the top of the file. Which leads to this:
>
> My tests operated differently in strict vs normal mode. That means my code does,
> too. Testing both modes would be difficult to do in an automated fashion;
> essentially, you're left needing to choose to support one mode or the other.
> This goes back to the point I was making earlier this week: I worry that having
> two modes will lead to a schism in userland libraries: those that support
> strict, and those that do not; there will be little possibility of testing both.

I think this last bit is misguided. Your *tests* are running differently 
depending if they are in strict and weak mode, that is correct, but the 
code's behavior itself is not changing based on the test suite's strictness.

That does not mean your library is tested to run in mode X or Y, it just 
means your test suite's correctness relies on testing the PHP type hints 
in this case, and it breaks when you change the way the hints behave.

For users the code will work the same no matter if they are in strict or 
weak mode, but if they are in weak mode they should indeed watch out if 
they send floats they will be silently truncated as those are the rules 
of weak mode.

> In the end: kudos to everyone who is working on these patches and RFCs. I'm
> excited about scalar type hints in PHP 7!

I agree with Benjamin's conclusion that having both RFCs combined might 
be for the best. At the very least lossy float->int should be disabled 
in the STHv5's weak mode because that's dangerous and unlikely to occur IMO.

The other casting changes from STHcoerce I am not sure if they're for 
the best or not. I am a bit worried we change things arbitrarily based 
on who has a good argument not to change them, and we might end up with 
a completely inconsistent set of casting rules.

Cheers