# Scalar type hints and scalar type name aliases cause confuson

- Thread: https://externals.io/message/88753
- Original archive: https://news-web.php.net/php.internals/88753
- Started by Andrea Faulds on 2015-10-12T19:23:17+00:00
- Messages: 21
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #88753 — Andrea Faulds — 2015-10-12T19:23:17+00:00

URL: https://externals.io/message/88753#88753

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'?)

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?

Thanks!

[0] 
http://stackoverflow.com/questions/32665818/php-7-return-type-declarations-fatal-error

-- 
Andrea Faulds
http://ajf.me/

---

## #88763 — Paul Dragoonis — 2015-10-13T09:35:34+00:00

URL: https://externals.io/message/88753#88763 · In reply to: #88753

> 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'?)
>
> 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?
>
> Thanks!
>
> [0]
> http://stackoverflow.com/questions/32665818/php-7-return-type-declarations-fatal-error
>
>
Hi Andrea,

Can you go ahead and make a branch/PR to add these type aliases in? There's
no right or wrong answer to 'int' versus 'integer', so allowing devs to
continue to use either will be welcoming.



> --
> Andrea Faulds
> http://ajf.me/

---

## #88764 — Michael Wallner — 2015-10-13T10:42:02+00:00

URL: https://externals.io/message/88753#88764 · In reply to: #88753

> 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
> 
...
> 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'?)
> 
> Even if we can't reserve the names, I hope we can do the two other
> suggestions in time for release.

Additionally, we could say "instance of class ...".


-- 
Regards,
Mike

---

## #88765 — Peter Cowburn — 2015-10-13T10:47:43+00:00

URL: https://externals.io/message/88753#88765 · In reply to: #88753

> 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/

---

## #88766 — Andrea Faulds — 2015-10-13T10:59:33+00:00

URL: https://externals.io/message/88753#88766 · In reply to: #88765

Hi Peter,

Peter Cowburn wrote:
> I would much rather we use the full names for these types across the board.

I would mostly agree with you. Using the full English names whenever 
we're writing English, not code, makes sense. But we usually use 
int/float/etc. in code, like other languages do, and I don't see a good 
reason to change that.

> The manual uses them almost exclusively,

Not for type signatures it doesn't. It usually uses "int" and "bool".

> and I'd hazard a bet that it is
> many peoples' first choice when trying out the argument/return type
> declarations.

Yeah, and others will sometimes use them by 'mistake'. I know I 
certainly have. So we need to prevent this creating confusion.

> 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?

I don't want to allow them as aliases, because it means another thing to 
add to style guides. Some people would use 'float', some 'double', some 
would use 'int', some 'integer', some 'long'. It'd be much cleaner to 
just pick one and stick with it. Types don't need multiple names.

However, as you mention, many people are used to the other variants. So 
I'd like to reserve them and throw an error if you use them. Much better 
than people typing 'function format_number(double $number, long 
$digits)` and getting bewildered when it doesn't work.

Thanks.

-- 
Andrea Faulds
http://ajf.me/

---

## #88767 — Andrea Faulds — 2015-10-13T11:00:45+00:00

URL: https://externals.io/message/88753#88767 · In reply to: #88764

Hi Michael,

Michael Wallner wrote:
> 
> > […]
>
> Additionally, we could say "instance of class ...".
>

We could do that, though it's already 'instance of'. Not sure on this one.

Thanks.

-- 
Andrea Faulds
http://ajf.me/

---

## #88768 — Derick Rethans — 2015-10-13T11:08:44+00:00

URL: https://externals.io/message/88753#88768 · In reply to: #88753

> 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

---

## #88769 — Kalle Sommer Nielsen — 2015-10-13T11:11:03+00:00

URL: https://externals.io/message/88753#88769 · In reply to: #88768

2015-10-13 13:08 GMT+02:00 Derick Rethans <derick@php.net>:
> What about double vs float? Another common combination.

(or "real" -- just to compliment the typecast)

</joke> =P



-- 
regards,

Kalle Sommer Nielsen
kalle@php.net

---

## #88770 — Derick Rethans — 2015-10-13T11:11:09+00:00

URL: https://externals.io/message/88753#88770 · In reply to: #88766

> Peter Cowburn wrote:
> 
> > […]
> 
> I don't want to allow them as aliases, because it means another thing 
> to add to style guides. Some people would use 'float', some 'double', 
> some would use 'int', some 'integer', some 'long'. It'd be much 
> cleaner to just pick one and stick with it. Types don't need multiple 
> names.

Having aliases is probably what I feel most strongly against as well.

cheers,
Derick

-- 
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine

---

## #88771 — Peter Cowburn — 2015-10-13T11:21:33+00:00

URL: https://externals.io/message/88753#88771 · In reply to: #88766

> Hi Peter,
>
> Peter Cowburn wrote:
>
> > […]
>
> I would mostly agree with you. Using the full English names whenever we're
> writing English, not code, makes sense. But we usually use int/float/etc.
> in code, like other languages do, and I don't see a good reason to change
> that.
>
> The manual uses them almost exclusively,
> > […]
>
> Not for type signatures it doesn't. It usually uses "int" and "bool".


I said "almost" for a reason. More clearly, we use the long names in prose
and by convention the short ones in the function prototypes.


>
>
> and I'd hazard a bet that it is
> > […]
>
> Yeah, and others will sometimes use them by 'mistake'. I know I certainly
> have. So we need to prevent this creating confusion.


I would say that more confusion will arise from trying to use something
that comes naturally (e.g. "integer") and getting an error, than having it
"just work".


>
>
> Failing that, at least making them available as aliases is a good thing in
> > […]
>
> I don't want to allow them as aliases, because it means another thing to
> add to style guides. Some people would use 'float', some 'double', some
> would use 'int', some 'integer', some 'long'. It'd be much cleaner to just
> pick one and stick with it. Types don't need multiple names.
>

So what if there is more than one way to say "hey, I want an integer here",
particularly when they're super-duper common terms that are used
everywhere. (I'm talking about "boolean" and "integer" specifically,
however if someone wants to use "long", or "double", or "real" then why the
hell stop them?


>
> However, as you mention, many people are used to the other variants. So
> I'd like to reserve them and throw an error if you use them. Much better
> than people typing 'function format_number(double $number, long $digits)`
> and getting bewildered when it doesn't work.
>

-1 to throwing an error, that's just completely the wrong direction in my
view. I'd much rather your example work.


>
> Thanks.
>
>
> --
> Andrea Faulds
> http://ajf.me/

---

## #88773 — Andrea Faulds — 2015-10-13T13:32:34+00:00

URL: https://externals.io/message/88753#88773 · In reply to: #88763

Hi Paul,

Paul Dragoonis wrote:
> 
>
> Hi Andrea,
>
> Can you go ahead and make a branch/PR to add these type aliases in? There's
> no right or wrong answer to 'int' versus 'integer', so allowing devs to
> continue to use either will be welcoming.
>

I've written a pull request (doesn't have tests yet) that makes the 
other type names produce helpful error messages:
https://github.com/php/php-src/pull/1572

e.g.

     $ ./sapi/cli/php -r 'function foo(): long {}'

     Fatal error: 'long' is not a valid type hint, use 'int' instead in 
Command line code on line 1

This would completely solve the confusion issue, I think. A crystal 
clear error message.

As I've said in a different email, I don't like the idea of allowing the 
aliases because it'd be another set of coding style differences we don't 
need. This lets us pick one name and stick with it, without causing 
confusion.

Thanks.

-- 
Andrea Faulds
http://ajf.me/

---

## #88774 — Andrea Faulds — 2015-10-13T13:37:19+00:00

URL: https://externals.io/message/88753#88774 · In reply to: #88771

Hi,

Peter Cowburn wrote:
> 
>
> > […]
>
>
> I said "almost" for a reason. More clearly, we use the long names in prose
> and by convention the short ones in the function prototypes.

Oh, right. My bad.

>
> I would say that more confusion will arise from trying to use something
> that comes naturally (e.g. "integer") and getting an error, than having it
> "just work".
>

People might be slightly surprised it's not allowed, but it'd be very 
clear what was wrong with the code and how to fix it, so it's not really 
a problem.

>
> So what if there is more than one way to say "hey, I want an integer here",
> particularly when they're super-duper common terms that are used
> everywhere. (I'm talking about "boolean" and "integer" specifically,
> however if someone wants to use "long", or "double", or "real" then why the
> hell stop them?
>

They're not used in source code much, though.

Thanks.

-- 
Andrea Faulds
http://ajf.me/

---

## #88775 — Andrea Faulds — 2015-10-13T13:44:49+00:00

URL: https://externals.io/message/88753#88775 · In reply to: #88768

Hi Derick,

Derick Rethans wrote:
> 
>
> > […]
>
> <snip>
>
> > […]
>
> What about double vs float? Another common combination.

Oh yeah, that's a bit of an issue. Since I changed it, PHP 7 doesn't say 
'double' in its type error messages any more, but there's still going to 
be people who'd expect that to work. So, my patch to reserve and produce 
errors includes 'double'.

>
> This is also an issue for argument typehints:

Exactly the same issue, yes. I just used return types for my examples, 
sorry if that was unclear.

>
> 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>")
>

It does. Could be improved slightly by the addition of a comma before 
the second 'in'.

> for:
>
> <?php
> declare(type=strict);
> function foo(integer $a) { }
> foo(42);
> ?>
>
> > […]
>
> With a parse error mentioning 'illegal token' or something like that?

Yeah. My current patch does this:

     ./sapi/cli/php -r 'function foo(): long {}'

     Fatal error: 'long' is not a valid type hint, use 'int' instead in 
Command line code on line 1

If you try to use it as a the name of a class/interface/trait, it 
produces the usual error for reserved class name.

>
> Well, that's what we have RCs for. And there are a few more coming up!
>

Yes, perhaps I shouldn't give up just yet.

>
> I'd find that nannying :)
>

It *is* a bit annoying, especially if you actually intended to have a 
class by that name.

>
> 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
>

That sounds good, albeit a little verbose.

Thanks!
-- 
Andrea Faulds
http://ajf.me/

---

## #88776 — Rowan Collins — 2015-10-13T13:56:17+00:00

URL: https://externals.io/message/88753#88776 · In reply to: #88767

Andrea Faulds wrote on 13/10/2015 12:00:
> Hi Michael,
>
> Michael Wallner wrote:
> > […]
>
> We could do that, though it's already 'instance of'. Not sure on this 
> one. 


It's not necessarily a class you're requiring an instance of, it could 
(and according to some design disciplines "should") be an interface. I 
think the "did you mean..." is more useful if we don't make everything 
alias.

Regards,
-- 
Rowan Collins
[IMSoP]

---

## #88781 — Anthony Ferrara — 2015-10-13T15:40:45+00:00

URL: https://externals.io/message/88753#88781 · In reply to: #88776

All,


> Andrea Faulds wrote on 13/10/2015 12:00:
> > […]
>
>
>
> It's not necessarily a class you're requiring an instance of, it could (and
> according to some design disciplines "should") be an interface. I think the
> "did you mean..." is more useful if we don't make everything alias.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>


I think it's important to clean up these error messages and make it
easier to find the root problem.

With that said, I strongly believe that adding new reserved classes is
the wrong way to do that. Part of the problem is inconsistency around
what we call types in the first place. This leads to confusion around
what types people expect and how they expect them.

An example is the fact that types are different all over the place.
Cast tokens, the return of `gettype()`, documentation, etc.

Everything is inconsistent. And reserving extra types because of this
inconsistency does nothing to actually fix the problem.

Instead, my suggestion would be to double-down on clarifying that
"int"/"float"/"bool"/etc are the canonical correct versions, and
everything else is an alias. In future versions (likely 8, but
possibly earlier) we could deprecate the aliases, to keep things far
more consistent.

Reserving more classes now (both 7.0 and this late in the RC process)
is IMHO not a great idea. Either side sucks (whichever we do we're
wrong), but at least not reserving gives us a path towards cleaning it
up rather than making it worse.

I like Derick's suggestion (though removing "class"):

Fatal error: Uncaught TypeError: Return value of foo() must be an
instance of boolean, scalar boolean returned

The "instance" says it's an object.

The rest of it becomes a documentation problem. We're already mostly
consistent in the docs (all of the signatures use the correct tokens),
so it shouldn't be hard to finish that off...

My $0.02 at least.

Anthony

---

## #88783 — Adam Harvey — 2015-10-13T17:38:47+00:00

URL: https://externals.io/message/88753#88783 · In reply to: #88773

(Sorry Andrea, I'm picking on your e-mail because it's easiest, but
it's a general response to the thread.)


> e.g.
>
>     $ ./sapi/cli/php -r 'function foo(): long {}'
>
>     Fatal error: 'long' is not a valid type hint, use 'int' instead in
> Command line code on line 1
>
> This would completely solve the confusion issue, I think. A crystal clear
> error message.

It is a good error message, but I disagree with the premise behind it:

> As I've said in a different email, I don't like the idea of allowing the
> aliases because it'd be another set of coding style differences we don't
> need. This lets us pick one name and stick with it, without causing
> confusion.

I agree that we should do something, but I think we should alias.

We allow both "int" and "integer" in `settype()` and we allow it in type
casting — the two other places where a user can specify a type for
conversion. I still think it's a poor choice to not allow both in type
declarations: while I'm generally a fan of having one way to do
things, I believe that the inconsistency in the language is worse than
the potential ambiguity in style guides.

Hell, _I_ still can't remember which out of "int" and "integer" is the
right one, and I've now written a decent amount of PHP 7 code _and_
wrote half of the documentation for this.

Plus, if we error when "integer" is used, we've moved people's cheese
anyway (by disallowing the class name). Let's not compound that by
forcing them to do busywork.

Adam, who hopes that anecdote doesn't say more about his working
memory than the design of the language.

---

## #88784 — Dmitry Stogov — 2015-10-13T20:16:07+00:00

URL: https://externals.io/message/88753#88784 · In reply to: #88781

On Tue, Oct 13, 2015 at 6:40 PM, Anthony Ferrara <ircmaxell@gmail.com>
wrote:

> All,
>
> On Tue, Oct 13, 2015 at 9:56 AM, Rowan Collins <rowan.collins@gmail.com>
> wrote:
> > […]
> one.
> > […]
> (and
> > […]
> the
> > […]
>
>
> I think it's important to clean up these error messages and make it
> easier to find the root problem.
>
> With that said, I strongly believe that adding new reserved classes is
> the wrong way to do that. Part of the problem is inconsistency around
> what we call types in the first place. This leads to confusion around
> what types people expect and how they expect them.
>
> An example is the fact that types are different all over the place.
> Cast tokens, the return of `gettype()`, documentation, etc.
>
> Everything is inconsistent. And reserving extra types because of this
> inconsistency does nothing to actually fix the problem.
>
> Instead, my suggestion would be to double-down on clarifying that
> "int"/"float"/"bool"/etc are the canonical correct versions, and
> everything else is an alias. In future versions (likely 8, but
> possibly earlier) we could deprecate the aliases, to keep things far
> more consistent.
>
> Reserving more classes now (both 7.0 and this late in the RC process)
> is IMHO not a great idea. Either side sucks (whichever we do we're
> wrong), but at least not reserving gives us a path towards cleaning it
> up rather than making it worse.
>
> I like Derick's suggestion (though removing "class"):
>
> Fatal error: Uncaught TypeError: Return value of foo() must be an
> instance of boolean, scalar boolean returned
>

I also don't like reserving new class names or limiting their use.
The message above looks clear and it shouldn't be a big problem to
implement the fix.
This fix shouldn't change anything except error message, so it'll make
minimal risk for 7.0 release process.

Thanks. Dmitry.


>
> The "instance" says it's an object.
>
> The rest of it becomes a documentation problem. We're already mostly
> consistent in the docs (all of the signatures use the correct tokens),
> so it shouldn't be hard to finish that off...
>
> My $0.02 at least.
>
> Anthony

---

## #88785 — Andrea Faulds — 2015-10-13T22:49:27+00:00

URL: https://externals.io/message/88753#88785 · In reply to: #88783

Hi Adam,

Adam Harvey wrote:
> (Sorry Andrea, I'm picking on your e-mail because it's easiest, but
> it's a general response to the thread.)

Ah, don't worry about it.

> I agree that we should do something, but I think we should alias.
>
> We allow both "int" and "integer" in `settype()` and we allow it in type
> casting — the two other places where a user can specify a type for
> conversion.

We also support 'real' and 'binary' in casts, but these are quite rare, 
and I think (int) is a lot more common than (integer), heck, the manual 
uses it.

> I still think it's a poor choice to not allow both in type
> declarations: while I'm generally a fan of having one way to do
> things, I believe that the inconsistency in the language is worse than
> the potential ambiguity in style guides.

Well, we could support the full set of names (int, integer, long, float, 
double, real, string, binary, bool, boolean) everywhere, but this is a 
bit unruly. It's better to pick one and stick to it, and discourage the 
us of the others or slowly phase them out.

>
> Hell, _I_ still can't remember which out of "int" and "integer" is the
> right one, and I've now written a decent amount of PHP 7 code _and_
> wrote half of the documentation for this.

The rule seems to be 'integer' in English, 'int' in code, for the most part.

> Plus, if we error when "integer" is used, we've moved people's cheese
> anyway (by disallowing the class name). Let's not compound that by
> forcing them to do busywork.

I think this would drill into you that it's 'int' not 'integer' pretty 
quickly, so it wouldn't become annoying.

>
> Adam, who hopes that anecdote doesn't say more about his working
> memory than the design of the language.
>

PHP is a confusing behemoth, don't worry, you're not alone :)

Thanks.

-- 
Andrea Faulds
http://ajf.me/

---

## #88786 — Andrea Faulds — 2015-10-13T22:52:50+00:00

URL: https://externals.io/message/88753#88786 · In reply to: #88784

Hi Dmitry,

Dmitry Stogov wrote:
>
> I also don't like reserving new class names or limiting their use.
> The message above looks clear and it shouldn't be a big problem to
> implement the fix.
> This fix shouldn't change anything except error message, so it'll make
> minimal risk for 7.0 release process.
>

Just changing error messages would work, but it's an unclean solution. 
It would be changing existing naming conventions ('integer' in English, 
'int' in code). Still, it's better than nothing if we can't reserve the 
names.

Thanks.

-- 
Andrea Faulds
http://ajf.me/

---

## #88787 — Peter Cowburn — 2015-10-14T08:43:58+00:00

URL: https://externals.io/message/88753#88787 · In reply to: #88785

> Hi Adam,
>
> Adam Harvey wrote:
>
> > […]
>
> Ah, don't worry about it.
>
> I agree that we should do something, but I think we should alias.
> > […]
>
> We also support 'real' and 'binary' in casts, but these are quite rare,
> and I think (int) is a lot more common than (integer), heck, the manual
> uses it.
>
> I still think it's a poor choice to not allow both in type
> > […]
>
> Well, we could support the full set of names (int, integer, long, float,
> double, real, string, binary, bool, boolean) everywhere, but this is a bit
> unruly. It's better to pick one and stick to it, and discourage the us of
> the others or slowly phase them out.


I'm going to keep beating this drum, but I disagree with that last
statement.  We *should* at the very least support both full and short names
for "int" and "bool": again, why stomp on people's muscle memory over
something so utterly trivial to support?  The only argument that I've
gleaned from this thread is "but, but, it's *inconsistent*" and that is not
something I disagree with at all. I simply prefer to support them, clearly
most others here don't.

An arbitrary code search shows that, for people currently documenting their
arguments with phpdoc, a non-trivial number of people choose the longer
terms for bool/int. [1] [2]



> Hell, _I_ still can't remember which out of "int" and "integer" is the
> > […]
>
This. So much this. Just like you, I keep typing "integer", and "boolean".
Maybe us folks on the documentation team have some mental deficiency that
the more internals folks don't have? (I'm only half-joking there.)


>
> The rule seems to be 'integer' in English, 'int' in code, for the most
> part.


I'd agree with "for the most part" but I disagree with that part being a
large enough part to ignore the other parts.


>
> Plus, if we error when "integer" is used, we've moved people's cheese
> > […]
>
> I think this would drill into you that it's 'int' not 'integer' pretty
> quickly, so it wouldn't become annoying.


It's int. It's int. It's int. It's int.  For this to be resolved, at least
for me, personally, there's going to need to be a lot more drilling. I like
to think that I'm not alone in this respect, but maybe that's not the case.


>
>
> > […]
Peter, who is a little tired of the folks beating the "more errors please"
drum.


>
> PHP is a confusing behemoth, don't worry, you're not alone :)
>
> Thanks.
>
> --
> Andrea Faulds
> http://ajf.me/
>
> --
> 
> 
>
>
[1] "@param boolean"
https://github.com/search?l=php&q=%22%40param+boolean%22&ref=searchresults&type=Code&utf8=%E2%9C%93
[2] "@param integer"
https://github.com/search?l=php&q=%22%40param+integer%22&ref=searchresults&type=Code&utf8=%E2%9C%93

---

## #88789 — Anatol Belski — 2015-10-14T09:57:32+00:00

URL: https://externals.io/message/88753#88789 · In reply to: #88786

Hi Andrea,

> -----Original Message-----
> From: Andrea Faulds [mailto:ajf@ajf.me]
> Sent: Wednesday, October 14, 2015 12:53 AM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] Scalar type hints and scalar type name aliases
> causeconfuson
> 
> Hi Dmitry,
> 
> Dmitry Stogov wrote:
> > […]
> 
> Just changing error messages would work, but it's an unclean solution.
> It would be changing existing naming conventions ('integer' in English, 'int' in
> code). Still, it's better than nothing if we can't reserve the names.
> 
People already ported a lot of stuff to 7.0, or get already trained, etc. So changing the error message looks like the only how far we can go at current stage. It is clear enough to express the necessary error, and it is soft enough to will possibly break some unit tests but not the actual codes.

Thanks

Anatol