Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88768
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 82.113.146.227 as permitted sender)
Date: Tue, 13 Oct 2015 12:08:44 +0100 (BST)
To: Andrea Faulds <ajf@ajf.me>
cc: PHP Developers Mailing List <internals@lists.php.net>
In-Reply-To: <5C.21.16518.AA80C165@pb1.pair.com>
Message-ID: <alpine.DEB.2.20.1510131200430.3813@whisky.home.derickrethans.nl>
References: <5C.21.16518.AA80C165@pb1.pair.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Subject: Re: [PHP-DEV] Scalar type hints and scalar type name aliases cause
 confuson
From: derick@php.net (Derick Rethans)

On Mon, 12 Oct 2015, Andrea Faulds wrote:

> you'll get the following error:
> 
>     Fatal error: Uncaught TypeError: Return value of foo() must be an instance
> of integer, integer returned

<snip>

> you'd get this:
> 
>     Fatal error: Uncaught TypeError: Return value of foo() must be an instance
> of boolean, boolean returned

What about double vs float? Another common combination.

This is also an issue for argument typehints:

TypeError: Argument 1 passed to foo() must be an instance of integer, 
integer given, called in /tmp/scalar.php on line 7 in /tmp/scalar.php on 
line 3

(I also think, this reads odd with two times "in <filename> on line 
<x>")

for:

<?php
declare(type=strict);
function foo(integer $a) { }
foo(42);
?>

> To avoid confusion, I would like it if we reserve 'integer' and 'boolean'
> alongside 'int' and 'bool', and make them produce an error if used.

With a parse error mentioning 'illegal token' or something like that?

> This would catch out mistakes with people writing the wrong name for 
> the type hint, and as a bonus would prevent people from misreading 
> typehints for classes which actually have thse names, as no class with 
> that name would be allowed.

> However, we're getting close to release and this might force some people to
> rename classes again if changed, causing disruption, so we might not be able
> to do this.

Well, that's what we have RCs for. And there are a few more coming up!

> 
> Alongside or instead of that, though, we can do two other things to make this
> situation better.
> 
> First, we could make type error messages use 'int' and 'bool'. This feels
> somewhat wrong to me since integer and Boolean are the proper English names
> for the types. But we do use the short names in some other places, like
> var_dump, so this isn't so bad. This way, we get this slightly clearer error:
> 
>     Fatal error: Uncaught TypeError: Return value of foo() must be an instance
> of integer, int returned
> 
> Second, we could add a helpful note to the TypeError message when the type
> hint is for a class named 'integer' or 'boolean' and the value passed was an
> integer or Boolean, respectively. My patch (based on Anthony's original) for
> the earlier Scalar Type Hinting with Cast RFC did this. This would make things
> even clearer:
> 
>     Fatal error: Uncaught TypeError: Return value of foo() must be an instance
> of integer, int returned (did you mean to use the type hint 'int'?)

I'd find that nannying :) 

> Anyway, can we do something about this soon?

I'd prefer reservation of integer and boolean, but a better error 
message is okay too. I'd go with something like:

Fatal error: Uncaught TypeError: Return value of foo() must be an instance of class boolean, scalar boolean returned

cheers,
Derick