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:
- User land return types didn't stop the php, the current implementation
raise error to stop PHP from start, this may help debug problem. - 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
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:
- User land return types didn't stop the php, the current implementation
raise error to stop PHP from start, this may help debug problem.- 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
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?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:
- User land return types didn't stop the php, the current implementation
raise error to stop PHP from start, this may help debug problem.- 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
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.
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:
- User land return types didn't stop the php, the current
implementation
raise error to stop PHP from start, this may help debug problem.- 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
--
Reeze Xia
http://reeze.cn
merged into master with the proposed changes.
Thanks. Dmitry.
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.
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:
- User land return types didn't stop the php, the current
implementation
raise error to stop PHP from start, this may help debug problem.- 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--
Reeze Xia
http://reeze.cn
Thanks a lot!
merged into master with the proposed changes.
Thanks. Dmitry.
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.
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:
- User land return types didn't stop the php, the current
implementation
raise error to stop PHP from start, this may help debug problem.- 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--
Reeze Xia
http://reeze.cn
--
Reeze Xia
http://reeze.cn
Thanks a lot!
merged into master with the proposed changes.
Thanks. Dmitry.
Awesome, thank you!
--
Regards,
Mike