Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88765
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5C.21.16518.AA80C165@pb1.pair.com>
References: <5C.21.16518.AA80C165@pb1.pair.com>
Date: Tue, 13 Oct 2015 11:47:43 +0100
Message-ID: <CAPg3XxJqqigQGMKPJpz_DnE4q-pFJXd_Js7F16AM6ajiVRnpoA@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d043c7ff258e07b0521fa2f88
Subject: Re: [PHP-DEV] Scalar type hints and scalar type name aliases cause confuson
From: petercowburn@gmail.com (Peter Cowburn)

--f46d043c7ff258e07b0521fa2f88
Content-Type: text/plain; charset=UTF-8

On 12 October 2015 at 20:23, Andrea Faulds <ajf@ajf.me> wrote:

> Hi,
>
> As PHP 7 currently is, if you write this:
>
>     public function foo(): integer {
>         return 12;
>     }
>     $bar = foo();
>
> you'll get the following error:
>
>     Fatal error: Uncaught TypeError: Return value of foo() must be an
> instance of integer, integer returned
>
> Similarly, if you were to write this:
>
>     public function foo(): boolean {
>         return true;
>     }
>     $bar = $foo();
>
> you'd get this:
>
>     Fatal error: Uncaught TypeError: Return value of foo() must be an
> instance of boolean, boolean returned
>
> These are confusing and unhelpful error messages. The long-form names of
> types (integer, boolean) aren't accepted as type hints, only their
> short-form names (int, bool) are. Yet we didn't reserve the names 'integer'
> and 'boolean' so we could produce a helpful error message, so anyone who
> types these long names will have them interpreted as type hints for (likely
> non-existant) classes named 'integer' or 'boolean' respectively. That
> produces confusing error messages on its own, but worse, type hint errors
> use 'integer' and 'boolean' to describe the types of values expected or
> given. Together, these two issues mean you get the two incredibly confusing
> error messages above.
>
> This is not kind to the users of PHP. It will cause unneeded confusion.
> This isn't even a theoretical case, that first example was based on a real
> StackOverflow question.[0] Mistakenly typing 'integer' or 'boolean' instead
> of 'int' and 'bool' is not at all an unlikely error, especially since the
> PHP manual uses these in some places (we should probably fix that at some
> point, and make it use PHP's actual syntax for return types and variadics,
> but I digress...), and since the aforementioned type error messages use
> them.
>
> 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. 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.
>
> 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'm sure the "hint" would will get certain nay-sayers' skins crawling.


>
> Even if we can't reserve the names, I hope we can do the two other
> suggestions in time for release.
>
> By the way, this situation is at least partly my fault. For PHP 7 I fixed
> zend_parse_parameters and userland type hint errors consistent with regard
> to type names: always 'integer', never 'long' (which only ever occured for
> the expectation, not what was actually given, bizarrely), and also always
> 'float', never 'double'. I also made sure is_int was an alias of is_long
> and not vice-versa. Alas, I made the mistake of picking 'int' over
> 'integer' and 'bool' over 'boolean'.
>
> Anyway, can we do something about this soon?
>

I would much rather we use the full names for these types across the board.

The manual uses them almost exclusively, and I'd hazard a bet that it is
many peoples' first choice when trying out the argument/return type
declarations.

Failing that, at least making them available as aliases is a good thing in
my book.  I never understood the reluctance to make use of all existing
names when the type declarations discussions were going on. Fact is, people
are going to type "double", "long", etc. in their declarations... why get
in their way?




>
> Thanks!
>
> [0]
> http://stackoverflow.com/questions/32665818/php-7-return-type-declarations-fatal-error
>
> --
> Andrea Faulds
> http://ajf.me/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--f46d043c7ff258e07b0521fa2f88--