# [RFC] Support internal function return types

- Thread: https://externals.io/message/81858
- Original archive: https://news-web.php.net/php.internals/81858
- Started by reeze on 2015-02-05T03:54:02+00:00
- Messages: 7
- RFC: Return Type Declarations (Implemented (PHP 7.0)) — https://externals.io/rfc/return_types.md
- 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

---

## #81858 — reeze — 2015-02-05T03:54:02+00:00

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

Hi all,

RFC:  https://wiki.php.net/rfc/internal_function_return_types

I noticed that return types RFC[1] didn't support internal functions, I
just open a PR[2]  to support it.

There are some open issues we can discuss:

1. User land return types didn't stop the php, the current implementation
raise error to stop PHP from start, this may help debug problem.
2. User land return types didn't support Nullable types, but the RFC return
types internally support it, I think it is feature. is that acceptable?

Thank you.

---

[1] https://wiki.php.net/rfc/return_types
[2] https://github.com/php/php-src/pull/1050

---

## #81859 — reeze — 2015-02-05T04:01:23+00:00

URL: https://externals.io/message/81858#81859 · In reply to: #81858

PS:

There is no enough unit tests to cover all of the branches, if we want then
I have to add a bunch of for testing functions and classes in ZEND_DEBUG,
what is the better way?



> Hi all,
>
> RFC:  https://wiki.php.net/rfc/internal_function_return_types
>
> I noticed that return types RFC[1] didn't support internal functions, I
> just open a PR[2]  to support it.
>
> There are some open issues we can discuss:
>
> 1. User land return types didn't stop the php, the current implementation
> raise error to stop PHP from start, this may help debug problem.
> 2. User land return types didn't support Nullable types, but the RFC
> return types internally support it, I think it is feature. is that
> acceptable?
>
> Thank you.
>
> ---
>
> [1] https://wiki.php.net/rfc/return_types
> [2] https://github.com/php/php-src/pull/1050

---

## #81864 — Dmitry Stogov — 2015-02-05T06:31:56+00:00

URL: https://externals.io/message/81858#81864 · In reply to: #81859

Hi reeze,

The original "return type" patch was designed to support internal functions
as well.
So I think, this is just a good addition.

Only one note:
I'm not sure, if we need the addition check in ZEND_DO_FCALL handler.
On one hand it verifies that internal function returns proper result (but
they MUST do it).
On the other hand, it also slowdowns each additional call.

Instead of modifying zend_verify_return_type() I would add
zend_verify_internal_return_type(),
and use: ZEND_ASSERT((fbc->common.fn_flags & ZEND_ACC_HAS_RETURN_TYPE) &&
zend_verify_internal_return_type(fbc, EX_VAR(opline->result.var)));

This would allow catching error in DEBUG build, but won't slowdown RELEASE
build.

If you agree, I may just commit this.

Thanks. Dmitry.



> PS:
>
> There is no enough unit tests to cover all of the branches, if we want then
> I have to add a bunch of for testing functions and classes in ZEND_DEBUG,
> what is the better way?
>
> 
>
> > […]

---

## #81865 — reeze — 2015-02-05T06:37:11+00:00

URL: https://externals.io/message/81858#81865 · In reply to: #81864

Hi Dmitry,



> Hi reeze,
>
> The original "return type" patch was designed to support internal
> functions as well.
> So I think, this is just a good addition.
>
Yes :)

>
> Only one note:
> I'm not sure, if we need the addition check in ZEND_DO_FCALL handler.
> On one hand it verifies that internal function returns proper result (but
> they MUST do it).
> On the other hand, it also slowdowns each additional call.
>
> Instead of modifying zend_verify_return_type() I would add
> zend_verify_internal_return_type(),
> and use: ZEND_ASSERT((fbc->common.fn_flags & ZEND_ACC_HAS_RETURN_TYPE) &&
> zend_verify_internal_return_type(fbc, EX_VAR(opline->result.var)));
>
> This would allow catching error in DEBUG build, but won't slowdown RELEASE
> build.
>
> If you agree, I may just commit this.
>

Sure!  Thank you!


>
> Thanks. Dmitry.
>
> 
>
> > […]
>
>


-- 
Reeze Xia
http://reeze.cn

---

## #81869 — Dmitry Stogov — 2015-02-05T08:03:41+00:00

URL: https://externals.io/message/81858#81869 · In reply to: #81865

merged into master with the proposed changes.

Thanks. Dmitry.



> Hi Dmitry,
>
> 
>
> > […]
> Yes :)
>
> > […]
>
> Sure!  Thank you!
>
>
> > […]
>
>
> --
> Reeze Xia
> http://reeze.cn

---

## #81870 — reeze — 2015-02-05T08:05:54+00:00

URL: https://externals.io/message/81858#81870 · In reply to: #81869

Thanks a lot!



> merged into master with the proposed changes.
>
> Thanks. Dmitry.
>
> 
>
> > […]
>
>


-- 
Reeze Xia
http://reeze.cn

---

## #81872 — Michael Wallner — 2015-02-05T08:23:08+00:00

URL: https://externals.io/message/81858#81872 · In reply to: #81870

> Thanks a lot!
> 
> 
> 
> > […]

Awesome, thank you!

-- 
Regards,
Mike