# [RFC] Type hints (parameter and return value)

- Thread: https://externals.io/message/37049
- Original archive: https://news-web.php.net/php.internals/37049
- Started by Felipe Pena on 2008-04-17T03:50:55+00:00
- Messages: 31
- Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/37049.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #37049 — Felipe Pena — 2008-04-17T03:50:55+00:00

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

Hello again!

Now with both parameter and return value type hints.

For parameter type hints, i have completed the actual implementation
with the leftover php types:
- string (binary string and unicode)
- integer (accepting numeric string too)
- double (accepting numeric string too)
- boolean ('0', '1', true, false)
- resource
- object

(Yes, following our dynamic typing)


Since then, the patch also includes new methods to Reflection:
- isInt()
- isDouble()
- isBool()
- isString()
- isObject()
- isResource()


And for return value, i have modified and improved the previous patch,
and now it is using only the "(type)" notation. Hence, that
implementation doesn't make any BC break.


Examples, patches and tests: http://wiki.php.net/rfc/typehint


Thanks.

-- 
Regards,
Felipe Pena.

---

## #37052 — Arvids Godjuks — 2008-04-17T09:01:24+00:00

URL: https://externals.io/message/37049#37052 · In reply to: #37049

What about types like
array
mixed

Ok, for "mixed"  we may not use type hinting at all - does patch allow to
hint only part of function args?
If we have a function, witch takes as 1st argument array or string and other
args should have strict types or just use call like myFunc(Array($string),
.....) ? This is just to know this for sure.

2008/4/17, Felipe Pena <felipensp@gmail.com>:
>
> Hello again!
>
> Now with both parameter and return value type hints.
>
> For parameter type hints, i have completed the actual implementation
> with the leftover php types:
> - string (binary string and unicode)
> - integer (accepting numeric string too)
> - double (accepting numeric string too)
> - boolean ('0', '1', true, false)
> - resource
> - object
>
> (Yes, following our dynamic typing)
>
>
> Since then, the patch also includes new methods to Reflection:
> - isInt()
> - isDouble()
> - isBool()
> - isString()
> - isObject()
> - isResource()
>
>
> And for return value, i have modified and improved the previous patch,
> and now it is using only the "(type)" notation. Hence, that
> implementation doesn't make any BC break.
>
>
> Examples, patches and tests: http://wiki.php.net/rfc/typehint
>
>
> Thanks.
>
> --
> Regards,
> Felipe Pena.

---

## #37053 — Lucas van Dijk — 2008-04-17T09:34:32+00:00

URL: https://externals.io/message/37049#37053 · In reply to: #37052

Array is already built in, and for mixed, as you already mentioned, indeed
no type hinting. I definitely want this implemented, +1 from me.

On Thu, Apr 17, 2008 at 11:01 AM, Arvids Godjuks <arvids.godjuks@gmail.com>
wrote:

> What about types like
> array
> mixed
>
> Ok, for "mixed"  we may not use type hinting at all - does patch allow to
> hint only part of function args?
> If we have a function, witch takes as 1st argument array or string and
> other
> args should have strict types or just use call like myFunc(Array($string),
> .....) ? This is just to know this for sure.
>
> 2008/4/17, Felipe Pena <felipensp@gmail.com>:
> > […]
>



-- 
Lucas

---

## #37056 — Christian Schneider — 2008-04-17T11:48:50+00:00

URL: https://externals.io/message/37049#37056 · In reply to: #37049

Felipe Pena wrote:
> For parameter type hints, i have completed the actual implementation
> with the leftover php types:
> - string (binary string and unicode)
> - integer (accepting numeric string too)
> - double (accepting numeric string too)
> - boolean ('0', '1', true, false)
> - resource
> - object

I don't like the difference between
	function (int) test($value) { ... }
and
	function test(integer $value) { ... }

I don't think we should introduce two different names for something
which is basically the same. Even if there is (as I guess) a slight
difference (int *really* being int and integer allowing strings
containing numbers), which makes the WTF factor even higher IMHO.

Also about "New tokens (new keywords)": I haven't tried the patch so
excuse me asking. Does this mean $this->string is invalid because string
is a new keyword? Then I'd be strongly against having these new keywords.

Is there any performance impact for people not using type hints?

Just to make it clear: I think type hinting is a Bad Idea(tm) anyway but
*if* it is implemented I think you should consider the above points.

- Chris

---

## #37058 — Arvids Godjuks — 2008-04-17T12:00:44+00:00

URL: https://externals.io/message/37049#37058 · In reply to: #37056

Christian Schneider



> I don't like the difference between
>         function (int) test($value) { ... }
> and
>         function test(integer $value) { ... }


First is function return value should be int, second is function arg should
be int.
So full syntax will be like this

function (integer) test(integer $value) { ... }

That means function takes an integer as argument and returns integer value.
If any is violated - Catchable error will be thrown.

That's my understanding of this patch. Some more examples

function (resource) query(string $table, array $where = array(), array
$limit = array()) { ... }

function (array) getData(string $table, array $limit = array(0, 20), array
$where = array()) { /* cals query and generates an array from result */ }

etc.

---

## #37060 — Christian Schneider — 2008-04-17T12:14:24+00:00

URL: https://externals.io/message/37049#37060 · In reply to: #37058

Arvids Godjuks wrote:
> So full syntax will be like this
> function (integer) test(integer $value) { ... }

I guess you are right: int and integer seem to be aliase and both check
for int *or* numeric strings, not the type int.
It is also not clear if (string) accepts ints/floats which are often
valid values.

I think a table of which type hint accepts which values would be useful.

And there also remains the issue with the keywords where I'd like to be
enlightened :-)

- Chris

---

## #37061 — Paul Biggar — 2008-04-17T12:52:32+00:00

URL: https://externals.io/message/37049#37061 · In reply to: #37049

Hi,

Your current implementation seems to be inconsistent with both itself
and the rest of PHP. I hope this can be rectified before it is
included. PHP is inconsisent enough without adding more.


1.) There are a number of is_* functions. It seems obvious that they
should be consistent with this. So you're missing numeric and scalar.
I'm not clear if there is a is_unicode(), but if so, that should be
consistent too. (I believe scalar is particularly important, at a
language level, since mixed and object are provided).

2.) is_int has different semantics to the int type hint. Numeric
strings qualify as the latter, but not the former. In general this is
a problem. It seems type hints can only be made consistent if they
convert the actual parameter to the type which is hinted. (Note that
for call-by-reference, this will change the value in the caller, not
just the copy in the callee - I think this is a good idea). As an
example, this will fail, which it shouldnt: function y (int $x) {
assert (is_int($x); } y ("24");

3.) This doesnt seem to be integrated with class type hints, in the
codebase. I wonder why that is? (I don't care all that much, I'm just
wondering).

I hope we can get these ironed out.

Thanks in advance.
Paul



> Hello again!
>
>  Now with both parameter and return value type hints.
>
>  For parameter type hints, i have completed the actual implementation
>  with the leftover php types:
>  - string (binary string and unicode)
>  - integer (accepting numeric string too)
>  - double (accepting numeric string too)
>  - boolean ('0', '1', true, false)
>  - resource
>  - object
>
>  (Yes, following our dynamic typing)
>
>
>  Since then, the patch also includes new methods to Reflection:
>  - isInt()
>  - isDouble()
>  - isBool()
>  - isString()
>  - isObject()
>  - isResource()
>
>
>  And for return value, i have modified and improved the previous patch,
>  and now it is using only the "(type)" notation. Hence, that
>  implementation doesn't make any BC break.
>
>
>  Examples, patches and tests: http://wiki.php.net/rfc/typehint
>
>
>  Thanks.
>
>  --
>  Regards,
>  Felipe Pena.
>
>
>  --
>  
>  
>
>



-- 
Paul Biggar
paul.biggar@gmail.com

---

## #37065 — Sam Barrow — 2008-04-17T14:01:13+00:00

URL: https://externals.io/message/37049#37065 · In reply to: #37061

> Hi,
> 
> Your current implementation seems to be inconsistent with both itself
> and the rest of PHP. I hope this can be rectified before it is
> included. PHP is inconsisent enough without adding more.
> 
> 
> 1.) There are a number of is_* functions. It seems obvious that they
> should be consistent with this. So you're missing numeric and scalar.
> I'm not clear if there is a is_unicode(), but if so, that should be
> consistent too. (I believe scalar is particularly important, at a
> language level, since mixed and object are provided).
> 
> 2.) is_int has different semantics to the int type hint. Numeric
> strings qualify as the latter, but not the former. In general this is
> a problem. It seems type hints can only be made consistent if they
> convert the actual parameter to the type which is hinted. (Note that
> for call-by-reference, this will change the value in the caller, not
> just the copy in the callee - I think this is a good idea). As an
> example, this will fail, which it shouldnt: function y (int $x) {
> assert (is_int($x); } y ("24");

The problem with this is that there's not much point in converting the
value. PHP will do that anyway, making this kind of pointless.

> 3.) This doesnt seem to be integrated with class type hints, in the
> codebase. I wonder why that is? (I don't care all that much, I'm just
> wondering).

This works in a different way. Rather than just checking the type, it
checks the value (such as a numeric string).

Overall, I think type hinting should work by checking the type. If it
does not match, raise an error. For example, int means int, not numeric
string.
This only serves to include an additional type juggling system into php,
which is very confusing.

---

## #37066 — Alain Williams — 2008-04-17T14:13:13+00:00

URL: https://externals.io/message/37049#37066 · In reply to: #37065

> 

> > […]
> 
> The problem with this is that there's not much point in converting the
> value. PHP will do that anyway, making this kind of pointless.

If inside y() you have something like:

	for( $i = 0; $i < $x; $i++ )

you will end up converting $x to integer $x times ... which will eat
CPU if $x is large -- I tried it.

An:
	assert (is_int($x))
followed by:
	$x = (int)$x
is the way to go.

> This only serves to include an additional type juggling system into php,
> which is very confusing.

If you don't understand it: don't use it.

-- 
Alain Williams
Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256  http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
Chairman of UKUUG: http://www.ukuug.org/
#include <std_disclaimer.h

---

## #37067 — Paul Biggar — 2008-04-17T14:28:38+00:00

URL: https://externals.io/message/37049#37067 · In reply to: #37065

Hi Sam,


\>  > 2.) is_int has different semantics to the int type hint. Numeric
> > […]
>
>  The problem with this is that there's not much point in converting the
>  value. PHP will do that anyway, making this kind of pointless.

That is not quite correct. PHP's weak typing is somewhat inconsistent,
and in the example I included, it will not coerce the value of $x. An
'int' type hint is not the same as is_int (), which is a mistake.

It seems the easiest thing is to make the conversion mandatory at
call-time. Alternatives would include weakening `is_int()`, or making
the 'int' hint fail for numeric strings (as you mention below). I
believe these two solutions are not as good.



>  Overall, I think type hinting should work by checking the type. If it
>  does not match, raise an error. For example, int means int, not numeric
>  string.
>  This only serves to include an additional type juggling system into php,
>  which is very confusing.

This is one alternative. The aim should be consistency (or as you say,
avoiding confusion). This weak typing is already part of the language,
so I don't believe it is inconsistent, though your suggestion clearly
is. However, it is more consistent than, and therefore preferable to,
the current patch.



Thanks,
Paul

-- 
Paul Biggar
paul.biggar@gmail.com

---

## #37086 — Stanislav Malyshev — 2008-04-17T17:02:54+00:00

URL: https://externals.io/message/37049#37086 · In reply to: #37061

Hi!

> Your current implementation seems to be inconsistent with both itself
> and the rest of PHP. I hope this can be rectified before it is
> included. PHP is inconsisent enough without adding more.

If you talk about consistency, you should remember that right now no 
function and no feature in PHP relies on strict checking of primitive 
types.
-- 
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com

---

## #37087 — Stanislav Malyshev — 2008-04-17T17:06:02+00:00

URL: https://externals.io/message/37049#37087 · In reply to: #37065

Hi!

> The problem with this is that there's not much point in converting the
> value. PHP will do that anyway, making this kind of pointless.

There would be a point since PHP might convert to different type that 
you intended. Think of $foo = "My age is $age". If $age is supposed to 
be int, then converting int hint might help.

> Overall, I think type hinting should work by checking the type. If it
> does not match, raise an error. For example, int means int, not numeric
> string.

What code scenario would make it necessary to distinguish between number 
stored as string and number stored as binary?

> This only serves to include an additional type juggling system into php,
> which is very confusing.

There's already type juggling in PHP, and if you find it confusing, you 
find whole PHP and whole set of dynamic languages very confusing. I 
guess maybe C or Java would work better then :)
-- 
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com

---

## #37089 — Pierre Joye — 2008-04-17T17:07:49+00:00

URL: https://externals.io/message/37049#37089 · In reply to: #37086

Hi Stanislav,


> Hi!
>
>
> > […]
>
>  If you talk about consistency, you should remember that right now no
> function and no feature in PHP relies on strict checking of primitive types.

Please try to minimize redundant response (at least within 15 mins). I
think we all got that you are against type hints in PHP, that's plain
wrong to do it, etc, etc. Thanks for your understanding (reply to my
ICU questions instead :-D,

Cheers,
-- 
Pierre
http://blog.thepimp.net | http://www.libgd.org

---

## #37090 — Stanislav Malyshev — 2008-04-17T17:10:08+00:00

URL: https://externals.io/message/37049#37090 · In reply to: #37089

Hi!

> Please try to minimize redundant response (at least within 15 mins). I
> think we all got that you are against type hints in PHP, that's plain

Against strict type hints, yes.
-- 
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com

---

## #37092 — Sam Barrow — 2008-04-17T17:14:32+00:00

URL: https://externals.io/message/37049#37092 · In reply to: #37087

> Hi!
> 
> > […]
> 
> There would be a point since PHP might convert to different type that 
> you intended. Think of $foo = "My age is $age". If $age is supposed to 
> be int, then converting int hint might help.
> 
> > […]
> 
> What code scenario would make it necessary to distinguish between number 
> stored as string and number stored as binary?
> 
> > […]
> 
> There's already type juggling in PHP, and if you find it confusing, you 
> find whole PHP and whole set of dynamic languages very confusing. I 
> guess maybe C or Java would work better then :)

I understand it very well, but why have a whole other system of type
juggling? That would be duplicating type juggling functionality that's
already in there.

---

## #37097 — Derick Rethans — 2008-04-17T17:32:26+00:00

URL: https://externals.io/message/37049#37097 · In reply to: #37049

> Now with both parameter and return value type hints.
> 
> For parameter type hints, i have completed the actual implementation
> with the leftover php types:
> - string (binary string and unicode)
> - integer (accepting numeric string too)
> - double (accepting numeric string too)
> - boolean ('0', '1', true, false)

I think that the typehints should be strict, if you don't want 
strictness, don't use type hints.

regards,
Derick

-- 
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org

---

## #37099 — Stanislav Malyshev — 2008-04-17T17:37:42+00:00

URL: https://externals.io/message/37049#37099 · In reply to: #37092

> I understand it very well, but why have a whole other system of type

It's the same system. The same system that makes internal functions work.
-- 
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com

---

## #37102 — Paul Biggar — 2008-04-17T17:56:19+00:00

URL: https://externals.io/message/37049#37102 · In reply to: #37086

> > […]
>
>  If you talk about consistency, you should remember that right now no
> function and no feature in PHP relies on strict checking of primitive types.

That is not the case (or I am very much mistaken). In particular,
is_int, which I mentioned in my email, is predicated on the IS_LONG
type only.

Paul


-- 
Paul Biggar
paul.biggar@gmail.com

---

## #37109 — Stanislav Malyshev — 2008-04-17T18:22:19+00:00

URL: https://externals.io/message/37049#37109 · In reply to: #37102

Hi!

> > […]
> 
> That is not the case (or I am very much mistaken). In particular,
> is_int, which I mentioned in my email, is predicated on the IS_LONG
> type only.

Read that "no function except for a tiny handful of very special cases 
like is_* and serializes and probably one or two other functions that I 
forgot", ok?
-- 
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com

---

## #37110 — Paul Biggar — 2008-04-17T18:31:54+00:00

URL: https://externals.io/message/37049#37110 · In reply to: #37109

Hi,


> > […]
> types.
> > […]
>
>  Read that "no function except for a tiny handful of very special cases like
> is_* and serializes and probably one or two other functions that I forgot",
> ok?


is_* are the important functions, since they are the ones which most
resemble the type hints under discussion. Up until now, anyone
implementing this in user-land would use `is_int()`. It makes perfect
sense that type hints should mimic this behaviour. Not doing so would
be very inconsistent, and so confusing.


Paul


-- 
Paul Biggar
paul.biggar@gmail.com

---

## #37111 — Stanislav Malyshev — 2008-04-17T18:41:13+00:00

URL: https://externals.io/message/37049#37111 · In reply to: #37110

Hi!

> is_* are the important functions, since they are the ones which most
> resemble the type hints under discussion. Up until now, anyone

Circular argument here.

> implementing this in user-land would use `is_int()`. It makes perfect

No, you shouldn't do that - there's absolutely no reason to accept 1 and 
reject '1', unless you have some very rare and special circumstance. If 
you are using is_int for that, your code is wrong.

> sense that type hints should mimic this behaviour. Not doing so would
> be very inconsistent, and so confusing.

Could we stop using word "consistent" to replace "I like it"?
-- 
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com

---

## #37113 — Mark van der Velden — 2008-04-17T18:48:38+00:00

URL: https://externals.io/message/37049#37113 · In reply to: #37097

Derick Rethans wrote:
> 
> 
> > […]
> 
> I think that the typehints should be strict, if you don't want 
> strictness, don't use type hints.
+1

- Mark

---

## #37114 — Stanislav Malyshev — 2008-04-17T18:54:29+00:00

URL: https://externals.io/message/37049#37114 · In reply to: #37113

> > […]

Note that right now we already have non-strict typehints in most of the 
internal functions, so you *are* using them if you use PHP.
-- 
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com

---

## #37116 — Pierre Joye — 2008-04-17T18:55:44+00:00

URL: https://externals.io/message/37049#37116 · In reply to: #37111

>  Circular argument here.

No comment.

Cheers,
-- 
Pierre
http://blog.thepimp.net | http://www.libgd.org

---

## #37118 — Paul Biggar — 2008-04-17T19:43:46+00:00

URL: https://externals.io/message/37049#37118 · In reply to: #37111

> > […]
>
>  Circular argument here.

Yes, I phrased that badly. I believe it is fair to say that there
would be confusion over why is_int may fail after an 'int' type hint.
More generally, I think it is difficult to explain why an int type
hint does not guarantee an int.



> > […]
>
>  No, you shouldn't do that - there's absolutely no reason to accept 1 and
> reject '1', unless you have some very rare and special circumstance. If you
> are using is_int for that, your code is wrong.

That is very subjective. I doubt there is 'one true style' of PHP,
despite suggestions I see about 'the PHP way'.  But let us suppose you
would use an int cast instead to ensure you have an int (by type, not
coerced value). The behaviour I recommend is also consistent with
casting. It would be syntactic sugar for

function ($x) { $x = (int) ($x); ... }




> > […]
>
>  Could we stop using word "consistent" to replace "I like it"?

I am very deliberately not using "consistent" to replace "I like it",
except in the sense that I like consistency. It makes no sense to find
that you do not have an int, when you specify you must. I very much
mean consistency, and do not have a preference for the approach,
except that only one seems perfectly consistent in this case, which is
why I have recommended it.


Paul

-- 
Paul Biggar
paul.biggar@gmail.com

---

Next page: https://externals.io/message/37049.md?page=2