Re: [PHP-DEV] [RFC] noreturn type

[Aaron Piotrowski]

> On Mar 10, 2021, at 12:06 PM, Matthew Brown  wrote:
> 
> Hey,
> 
> Ondřej Mirtes and I present an RFC for the noreturn type:
> https://wiki.php.net/rfc/noreturn_type
> 
> The feature already exists in Hack (the primary inspiration) and is
> currently supported by our static analysis tools inside docblocks, and we
> feel there's a good argument for it to be supported by PHP itself.
> 
> Thanks,
> 
> Matt & Ondřej


Hi Matt & Ondřej,

I wanted to give my +1 to this proposal.

I was curious to see how fibers might interact with this declaration, since it 
is possible to create a fiber that can not return. So, I compiled your branch 
and gave it a try.

```
$fiber = new Fiber(function (): noreturn {
while (true) {
Fiber::suspend(\random_int(0, 100));
}
});

$result = $fiber->start();

for ($i = 0; $result; ++$i) {
echo $result, "\n";
$result = $fiber->resume();
}

echo "Generated ", $i, " numbers before generating zero.\n";
```

This short script works just as expected, cool! :-D

Cheers,
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Fibers

[韩天峰]

HiDan,


We have no commercial purpose on the swoole open source project.This is a 
purely technical project.
If possible, we can remove the name of swoole, contribute the source code of 
swoole-src to php-src, and transfer the copyright.
Here is just a technical discussion.My opinion is that if PHP will 
support fiber/green-threads, this is a major change, should redesign language 
syntax, standard library, ZendVM.
This proposal must be discussed extensively and in-depth,should not make 
a hasty decision.


There are 7 parts to consider with my experience:

EventLoop API


Fiber/Coroutine/GreenThread


IO-Scheduler (Socket/FileSystem/ChildProcess/Signal/Timer/Stdout/Stdin)


CPU-Scheduler


Compatible with existing extesions 
(php_streams/ext-sockets/ext-redis/ext-mysqli/ext-pdo-mysql/ext-curl ...) and 
builtin-functions (sleep/gethostbyname/proc_open/file_get_contents)


Service container,How to support php-fpm and provide a coroutine version 
of http server


Coroutine communication,How to pass messages between two coroutines

It’s nice to see php has such topic. This may be the key technology in the next 
generation of PHP.



Thanks


Tianfeng.Han


--Original--
From: "Dan Ackroyd"

RE: [PHP-DEV] Honour the Default Value of 'return' Statement According to the Function Signature

[Hamza Ahmad]

Thank you for providing me with the feedback, experts! Initially, I wanted 
empty returns in void functions. When I prepared the request, I included the 
other solutions that I felt important and worth adding. Is it not possible to 
go with empty returns in void functions? I agree that the code can be adjusted 
to fit the current environment; still, people avoid writing lengthy blocks of 
code. An empty return with defaults will help them with the code that is easier 
to maintain.
I clarified my stance on first email in a response to a respectable member of 
the list. I do not know why that email is not appearing on externals. I will 
make sure that next time I post an external URL that contains the changelog and 
do not clutter the mailing list.
I am again thankful to you all!
Best
Hamza Ahmad

-Original Message-
From: Mike Schinkel  
Sent: Thursday, March 11, 2021 10:05 PM
To: office.hamzaah...@gmail.com
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Honour the Default Value of 'return' Statement According 
to the Function Signature

> On Mar 10, 2021, at 10:37 PM, office.hamzaah...@gmail.com wrote:
> 
> Hello Internals,
> I congratulate you for the successful release of PHP 8.0.3. I also 
> appreciate your efforts to bring union types and return type hints.
> Although the type hints have made debugging more easier, it has 
> created another problem for those that use 'return' to end the 
> execution of a function or method call.

Welcome.

> There are mainly two usages of 'return'. First ends the execution of 
> the remaining statements. Second returns a value. The return type 
> hints aids with the second usage and ignores the former facility. In 
> other words, if one wants to avoid large code blocks i.e. the 
> conditional blocks, it can write like following.
> 
>  function foo()
> {
>   If (true /*condition1*/)
>   return;
> 
>   if (!false /*condition2*/)
>   return;
> 
>   /*the remaining part of a function*/
> };
> ?>

However, I agree with Larry.  This feels either like a code smell and/or could 
be handled with a variable.

This pattern can be very frustrating in other people's code when I either need 
to debug it or might want to debug it to learn the code because it requires 
setting IDE breakpoints in many places to be sure that catch an exit. And 
invariably I miss breakpointing a return when debugging and am left wondering 
what happened.  See https://youtrack.jetbrains.com/issue/WI-40862

As an alternate I developed a technique using `do{...} while(...)` in a novel 
way that I wish PHP supported more cleanly, but it nonetheless works great. 

The technique uses `do {...} while(false)` to create a block that break can 
exit early on guard clauses, for example (btw, I would return `null` instead of 
`'unknown'` and enclose the breaks in braces for the `if(...)` statement, but I 
wanted my example to be equivalent to yours):

 The above function returns null if conditions are met. Otherwise, it 
> returns no value. It was okay when there was no concept of return type 
> hints. When return types have been introduced, the behaviour needs to be 
> evolved, too.
> What if the return type was set 'int|float' in the above example? The 
> compiler would give following error:
> Fatal error: A function with return type must return a value 
> Similarly, a function with ': void' signature produceed that a 
> function may not return a value.
> To resolve such a problem, I request to honour the function signature 
> when you evaluate return statements. Instead of looking for no 'return'
> statements in ': void' functions, verify whether a function specifies 
> a return value. If the function returns a type other than the types 
> declared in the signature, it may produce wrong type error. If a 
> function with void returns a value i.e. contains a non-empty return 
> (return;) statement, the compiler may throw an error stating that a 
> function with void signature must not return a value.
> Likewise, 'return' may return an empty array if the return type was 
> set to array; the similar case applies to string, int, float, object 
> etcetera. In the case of ': void' signature, 'return' only ends the 
> execution and returns no value.
> PHP also allows to specify only returning 'false' from a function 
> call. What if you extend this functionality and allow specifying 
> literals including null? If nulls are also allowed, the backword 
> behaviour could be impleamented. For example:
> public function foo() : string| null;
> 
> Consider the following example for literals.
>  function get_nationality_string(int $country_code) : string | "unknown"
> {
>   return;
> };
> ?>
> 
> I am positive that you will consider my request and provide me with 
> the feedback in case of any inconsistency in my argument. I wish you 
> best of luck for the on-going work for the PHP 8.1.
> Best Regards
> Hamza Ahmad
> 
> --
> PHP Internals - PHP Runtime Development Mailing 

Re: [PHP-DEV] [VOTE] Fibers

[Aaron Piotrowski]

> On Mar 11, 2021, at 10:41 AM, Ben Ramsey  wrote:
> 
>> On Mar 11, 2021, at 10:29, Aaron Piotrowski  wrote:
>> 
>> There is not an internal API to create fibers at this time. However, I 
>> planned to collaborate with other internals developers to add this API (and 
>> of course with feedback from swoole developers), so this will be a feature 
>> available to PHP extensions.
>> 
> 
> 
> I know voting is currently on-going, but would it be out of order to add a 
> section to the RFC that states what you’ve said here?
> 
> Cheers,
> Ben
> 

Hi Ben,

I think this is appropriate, as it is merely adding information to the RFC to 
answer a question that was raised on the list.

I added a “Future Scope” section with the following text:

The current implementation does not provide an internal API for fibers for PHP 
extensions. This RFC focuses on the user space fiber API. An internal fiber 
APIwill be added, collaborating with other internal developers and using 
feedback from PHP extension developers, including Swoole, so fibers can be 
created and controlled from PHP extensions. An extension may still optionally 
provide their own custom fiber implementation, but an internal API would allow 
the extension to use the fiber implementation provided by PHP.

Cheers,
Aaron Piotrowski

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] noreturn type

[Rowan Tommins]

On 11 March 2021 19:39:26 GMT, Dan Ackroyd  wrote:
>Unfortunately people in the community have started doing what I
>feared, and using void as 'no value is returned', which is not what
>the language actually _does_.
>
>I realise the above might be slightly discombobulating if, for
>example, some people had written large static code analyzers that had
>misinterpreted void like this.


I think it is you that is misinterpreting things. The "void" keyword explicitly 
signals the intent "this function does not return a value". People find that a 
useful thing to signal, even if the language still allows the function to be 
used in expression context. They also find it useful to be reminded "Hey, you 
know this function you're using as an expression? That makes no sense, because 
it doesn't return anything."

You may not find that useful, but those that do are using "void" exactly as 
intended.

Regards,
Oh, and on this point:
-- 
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] noreturn type

[Rowan Tommins]

Hi Dan,

While I have some sympathy for your first point:

>I (and others) brought this up during the void RFC:
>https://news-web.php.net/php.internals/88990 and said that null was
>the right choice over void, as it matches what the language actually
>does.

I disagree with your second, which doesn't follow at all:

>That would have left void available to mean 'this function' does not
>exit normally.

Using "void" for this would be even more confusing than what we have now. If 
anything, "void" should have been reserved for an implementation that checked 
correct usage at the call site, as happens in other languages. Although, if 
someone can come up with an implementation of that, adding it with a suitable 
lead in time would still be possible.

It's also something of a moot point, since even if we introduced a null return 
type (which would be a subtly different feature from void as currently 
implemented), we couldn't suddenly repurpose a keyword that's already used. So 
if you think "never returns" is something worth representing, it will need a 
new keyword, several options for which have been proposed.

Regards,

-- 
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Fibers

[Dan Ackroyd]

Hi Twosee, Tianfeng.Han

I was drafting a longer reply to you both, but I realised I might be
missing some information.

Please could you disclose the commercial interests of the Swoole
maintainers, and the ties to the for profit companies that provide
services implementing Swoole?

Having people vote on RFCs who have ties to companies that provide
services via commercial entities isn't unprecedented. For example
zend.com has had employees who are involved in voting on RFCs, but to
a large extent that was done openly, with all of them using zend.com
email addresses.

twosee wrote:
> Of course, the Swoole community still expects to merge it into php-src at an 
> appropriate time.

What's your idea of an appropriate time and how do you plan to start
this conversation?

If something hasn't been merged back after 8 years, it sounds
reasonably unlikely that it's ever going to be merged back.

cheers
Dan
Ack

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] noreturn type

[Dan Ackroyd]

Hi Matt & Ondřej,

One of the things that makes PHP different from other languages (and
for better for a change) is that every function returns a value, even
where there is no explicit return statement.

This eliminates a large number of edge-cases in code like:

  function log_result(mixed $bar) {...}
  log_result($anyCallable());

is always valid in PHP, whereas in other languages similar code can
either refuse to compile, or error out when run, or other things like
'undefined' variables.

I.E. in other languages, there are three exit conditions:
 * no value returned
 * a value returned
 * function has no normal exit

And so other languages need to indicate between 'void' and 'no return'

But in PHP there are only two exit conditions*:
 * a value returned
 * function has no normal exit

I (and others) brought this up during the void RFC:
https://news-web.php.net/php.internals/88990 and said that null was
the right choice over void, as it matches what the language actually
does.

That would have left void available to mean 'this function' does not
exit normally.

Unfortunately people in the community have started doing what I
feared, and using void as 'no value is returned', which is not what
the language actually _does_.

I realise the above might be slightly discombobulating if, for
example, some people had written large static code analyzers that had
misinterpreted void like this.

I think we should introduce null. But we shouldn't introduce
'noreturn' even if a large number have misunderstood what the
behaviour of the language is. It might be appropriate for the other
languages that are listed in the other language section, but it's not
appropriate in PHP which is different to those languages.

cheers
Dan
Ack


* so the usage of null and void return types should be:

function returns(): null {
if (rand(0, 100) === 0) { throw new \Exception('Surprise!');}
// intentionally no code
}

function never_returns(): void {
if (rand(0, 100) === 0) { throw new \Exception('Surprise!');}
while (1) {}
}

For both of them, there are exceptions to the declared return type,
but otherwise 'returns' returns the value null, and 'never_returns'
never returns a value.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [PHP-DEV] [VOTE] Fibers

[Christian Schneider]

Am 11.03.2021 um 17:51 schrieb Chase Peeler :
> If someone is willing to do the work to
> add this to core, we aren't trading off other features in order to add it,
> and it doesn't cause BC breaks or other bugs, what is the reason to not add
> it?


Complexity, which might come back and bite us in the long run.

Note: I'm not talking about this specific feature, more in general. I just 
wanted to point out that there can be reasons to *not* add something even 
though it doesn't seem to have a drawback at the moment.

- Chris

Re: [PHP-DEV] [VOTE] Fibers

[Benjamin Eberlei]

On Wed, Mar 10, 2021 at 10:51 PM Kalle Sommer Nielsen  wrote:

> Den ons. 10. mar. 2021 kl. 20.22 skrev Dan Ackroyd  >:
> >
> > Hi internals,
> >
> > Well, technically this is addressed more to people who read internals.
> >
> > Please don't contact people off list putting pressure on them to vote
> > in a particular way.
> >
> > It _really_ is not appreciated, no matter how well intentioned the
> > sender thinks it is.
>
> For the sake of integrity, I believe the vote should be halted and
> restarted at a later date to prevent the influence of referenced email
> from having a favored vote. This has no relation to my personal vote
> on the matter of the RFC however.
>

If the email was sent by the RFC authors itself I would agree, but it was
not.

Stopping the vote because of this would provide precedent to bombard any
RFC vote by just emailing all voters a nasty email.

>
> --
> regards,
>
> Kalle Sommer Nielsen
> ka...@php.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Honour the Default Value of 'return' Statement According to the Function Signature

[Mike Schinkel]

> On Mar 10, 2021, at 10:37 PM, office.hamzaah...@gmail.com wrote:
> 
> Hello Internals,
> I congratulate you for the successful release of PHP 8.0.3. I also
> appreciate your efforts to bring union types and return type hints.
> Although the type hints have made debugging more easier, it has created
> another problem for those that use 'return' to end the execution of a
> function or method call.

Welcome.

> There are mainly two usages of 'return'. First ends the execution of the
> remaining statements. Second returns a value. The return type hints aids
> with the second usage and ignores the former facility. In other words, if
> one wants to avoid large code blocks i.e. the conditional blocks, it can
> write like following.
> 
>  function foo()
> {
>   If (true /*condition1*/)
>   return;
> 
>   if (!false /*condition2*/)
>   return;
> 
>   /*the remaining part of a function*/
> };
> ?>

However, I agree with Larry.  This feels either like a code smell and/or could 
be handled with a variable.

This pattern can be very frustrating in other people's code when I either need 
to debug it or might want to debug it to learn the code because it requires 
setting IDE breakpoints in many places to be sure that catch an exit. And 
invariably I miss breakpointing a return when debugging and am left wondering 
what happened.  See https://youtrack.jetbrains.com/issue/WI-40862

As an alternate I developed a technique using `do{...} while(...)` in a novel 
way that I wish PHP supported more cleanly, but it nonetheless works great. 

The technique uses `do {...} while(false)` to create a block that break can 
exit early on guard clauses, for example (btw, I would return `null` instead of 
`'unknown'` and enclose the breaks in braces for the `if(...)` statement, but I 
wanted my example to be equivalent to yours):

 The above function returns null if conditions are met. Otherwise, it returns
> no value. It was okay when there was no concept of return type hints. When
> return types have been introduced, the behaviour needs to be evolved, too.
> What if the return type was set 'int|float' in the above example? The
> compiler would give following error:
> Fatal error: A function with return type must return a value Similarly,
> a function with ': void' signature produceed that a function may not return
> a value.
> To resolve such a problem, I request to honour the function signature when
> you evaluate return statements. Instead of looking for no 'return'
> statements in ': void' functions, verify whether a function specifies a
> return value. If the function returns a type other than the types declared
> in the signature, it may produce wrong type error. If a function with void
> returns a value i.e. contains a non-empty return (return;) statement, the
> compiler may throw an error stating that a function with void signature must
> not return a value.
> Likewise, 'return' may return an empty array if the return type was set to
> array; the similar case applies to string, int, float, object etcetera. In
> the case of ': void' signature, 'return' only ends the execution and returns
> no value.
> PHP also allows to specify only returning 'false' from a function call. What
> if you extend this functionality and allow specifying literals including
> null? If nulls are also allowed, the backword behaviour could be
> impleamented. For example:
> public function foo() : string| null;
> 
> Consider the following example for literals.
>  function get_nationality_string(int $country_code) : string | "unknown"
> {
>   return;
> };
> ?>
> 
> I am positive that you will consider my request and provide me with the
> feedback in case of any inconsistency in my argument. I wish you best of
> luck for the on-going work for the PHP 8.1.
> Best Regards
> Hamza Ahmad
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
> 

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Honour the Default Value of 'return' Statement According to the Function Signature

[Chase Peeler]

On Thu, Mar 11, 2021 at 10:37 AM Larry Garfield 
wrote:

> On Thu, Mar 11, 2021, at 6:10 AM, Hamza Ahmad wrote:
> > Hi Victor,
> >
> > It does not contradict because it does not cover two different aspects.
> > First, return types specify the types of to be returned values. Second,
> > this request proposes a shorthand technique to avoid writing a single
> > line code multiple times. Third, it is similar to default argument
> > values that are also typed.
> >
> > Cheers!
>
> Greetings.  First, please don't top post.  This is a bottom-posting list.
>
> As to your proposal, it's a bit hard to follow because it sounds like
> you're suggesting an implicit "return of nothing" built on union types,
> when based on your follow ups what I think you're suggesting is something
> more like this:
>
> function foo(int $bar = 4): int = 0 {
>   if (is_even($bar)) {
> return; // Implicitly returns 0
>   }
>   return $bar * 2;
> }
>
> That is, allowing a default return value.  Union types aren't part of the
> picture.
>
> I can see how you got to the idea, but honestly I am not a fan.
> Primarily... I've never run into the situation you describe where multiple
> early-returns would have the same value.  Perhaps it's just because in
> those cases I end up combining the conditionals with an ||, but I don't see
> the problem you describe.  Different code paths should result in different
> results, or else why are they different code paths?
>
> So, code that's doing that I'd be suspicious of to begin with.
>
>
There are times, for the sake of readability, where I might break things up
into multiple if statements instead of combining them with an OR.

Sometimes you need to do additional work between conditionals as well:

if($id == 0){
   return null;
}

$record = $db->get($id);

if(empty($record)){
  return null;
}

Regardless, I think your solution below works just fine.


> Even if you did end up in such a situation, since you're dealing with a
> static value, setting the default internally within the function is trivial:
>
> function foo(int $bar = 4): int {
>   $default = 0;
>   if (is_even($bar)) {
> return $default;
>   }
>   return $bar * 2;
> }
>
> So basically, in the few cases where this isn't a code smell, it's
> unnecessary.
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] 回复：Re: [PHP-DEV] [VOTE] Fibers

[Chase Peeler]

On Thu, Mar 11, 2021 at 8:56 AM 韩天峰  wrote:

> Hi,
> I am come from Chinese, we may have some cultural differences, and there
> may be some difficulties in communication. I try to express my opinion.
> To be precise, the fiber can only be used for amphp and reactphp or other
> event-driven asynchronous IO frameworks developed using php.The RFC
> does not mention how an extension uses fiber.
> Fiber is not like threads or processes of operating system. It is not
> parallel, nor is it concurrent. This requires an event-driven scheduler to
> have practical value.Currently php does not have event-driven
> support. So normal web developers don’t know how to use fiber.It is
> for developers of asynchronous io programming.
> I just suggest first to provide a PECL extension like
> ext-event/ext-libevent, no need to be integrated into php now.Swoole
> is also provided to users as a PECL extension.
>
>
I want to answer this in a different way than Aaron did. Let's assume that
this is correct. No one will EVER use fibers except amphp and reactphp.
Let's also assume that it would work just fine as an extension (which Aaron
has shown already is not the case). If someone is willing to do the work to
add this to core, we aren't trading off other features in order to add it,
and it doesn't cause BC breaks or other bugs, what is the reason to not add
it?




>
> 
> 
> --原始邮件--
> 发件人: "Peter Stalman";
> 发送时间: 2021年3月11日(星期四) 下午2:37
> 收件人: "韩天峰";
> 抄送: "Aaron Piotrowski"; "php internals";
> 主题: Re: [PHP-DEV] [VOTE] Fibers
>
> 
>
> OnWed.,Mar.10,2021,02:16韩天峰,<
> ra...@swoole.comwrote:
>
>
> Iamafraidthatfibercanonlybeusedintheamphpframeworkandisof
> novaluetootherphpprojects.
> 
>
> Hi,
>
>
> Idliketoseeyouelaborateonthispoint.Areyouabletoprovide
> anythingtobackupthisclaim?
>
>
> Idontseeanythingthatisspecifictoamphp,notanythingtolimititto
>
> theiruse.FibersalsoexistoutsideofPHP,whileamphpdoesnt.
>
> Thanks,
> Peter



-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] [VOTE] Fibers

[Ben Ramsey]

> On Mar 11, 2021, at 10:29, Aaron Piotrowski  wrote:
> 
> There is not an internal API to create fibers at this time. However, I 
> planned to collaborate with other internals developers to add this API (and 
> of course with feedback from swoole developers), so this will be a feature 
> available to PHP extensions.
> 


I know voting is currently on-going, but would it be out of order to add a 
section to the RFC that states what you’ve said here?

Cheers,
Ben



signature.asc
Description: Message signed with OpenPGP

Re: [PHP-DEV] [VOTE] Fibers

[Aaron Piotrowski]

> On Mar 11, 2021, at 7:56 AM, 韩天峰  wrote:
> 
> The RFC does not mention how an extension uses fiber.
> 

Hi,

I forgot to address your point that the RFC does not mention how an extension 
uses fibers.

I did omit this from the RFC as I focused on the user API, as that is typically 
what PHP RFCs focus on, but this is an important question.

There is not an internal API to create fibers at this time. However, I planned 
to collaborate with other internals developers to add this API (and of course 
with feedback from swoole developers), so this will be a feature available to 
PHP extensions.

Aaron Piotrowski

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Fibers

[Aaron Piotrowski]

> Hi all!
> 
> A concern was raised off list that due to the complexity of the way this 
> feature interacts with the engine, it may be best to mark the feature as 
> experimental. This would allow some changes to be made to certain edge-case 
> behaviors and, while I don't think it would be necessary, the public API.
> 
> We (Niklas and I) agree with this and propose that if this feature is 
> accepted, it is marked as experimental through the 8.x release cycle or until 
> we're comfortable removing that label, whichever comes first.
> 
> Experimental in this context would mean fibers would be compiled and 
> available in all releases, but the documentation would denote that behavioral 
> and API changes may be made in future minor releases – use at your own risk.
> 
> As this feature is targeted at library authors and not average PHP users, we 
> believe there would be little effect to the community to take this step.
> 
> Cheers,
> Aaron Piotrowski
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
> 

Hi everyone!

I’m concerned my email above may have had the opposite effect from which I had 
hoped.

I think the Fiber implementation is sound and the API, mirroring that of Ruby, 
is proven and unlikely to require change.

There are certain edge case behaviors that I’m concerned may need to changed, 
such as the error reporting level that is active when a fiber is switched. If 
the @ operator is active, should it remain active after a fiber switch? Right 
now, it does not, the @ operator is on a per-fiber basis, restoring error 
reporting when switching fibers. Perhaps though this was the wrong decision. 
What I was hoping to accomplish with marking the feature as experimental was to 
get feedback on such behaviors and make sure we make the right choices.

Recent changes to the JIT also make fibers as an extension incompatible due to 
defining a user opcode handler. This is unfortunate, as cli apps including 
amphp and ReactPHP greatly benefited from the JIT: 
https://www.php.net/releases/8.0/en.php (see Relative JIT contribution to PHP 8 
performance). Integrating fibers in core will allow the opcode handler to be 
predefined.

Hopefully that provides some clarity to our intensions. Cheers!

Aaron Piotrowski

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Fibers

[Aaron Piotrowski]

> On Mar 11, 2021, at 7:56 AM, 韩天峰  wrote:
> 
> Hi,
> I am come from Chinese, we may have some cultural differences, and there may 
> be some difficulties in communication. I try to express my opinion.
> To be precise, the fiber can only be used for amphp and reactphp or other 
> event-driven asynchronous IO frameworks developed using php. The RFC does not 
> mention how an extension uses fiber.
> Fiber is not like threads or processes of operating system. It is not 
> parallel, nor is it concurrent. This requires an event-driven scheduler to 
> have practical value. Currently php does not have event-driven support. So 
> normal web developers don’t know how to use fiber. It is for developers of 
> asynchronous io programming. 
> I just suggest first to provide a PECL extension like ext-event/ext-libevent, 
> no need to be integrated into php now. Swoole is also provided to users as a 
> PECL extension.
> 

Hello,

I agree that this feature is targeted at libraries wishing to provide better 
async I/O. What I disagree with is that this means it should not be a part of 
PHP.

Whether many developers realize it or not, several commonly used libraries 
already contain some async I/O features, often implemented with promises, which 
have some API trade-offs to attempt to integrate async into typical synchronous 
code. Guzzle, Symfony, and Psalm are three commonly used libraries that have 
asynchronous APIs available.

Having fibers available in core will allow these libraries to offer async code 
with an improved, more intuitive API as well as expand their use of async I/O 
beyond what it typically has been used for, HTTP requests, to include 
databases, redis, file access, etc.

An event scheduler is needed for async I/O to work, but several implementations 
already exist in user space and work very well with fibers, as I and ReactPHP 
team can attest. Fibers are the key to integrating these event schedulers into 
the greater PHP community.

Swoole provides an entire large, opinionated framework for async coding. That’s 
fantastic! However, it is not a flexible tool that any library can use for a 
variety of purposes. It is more akin to choosing a framework such as Laravel or 
Yii to write your PHP app.

Event-driven programming is desperately needed in the PHP community. Right now 
PHP contains nearly all the tools for fantastic, clear, intuitive user space 
async code. This is the one missing piece.

Aaron Piotrowski

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Honour the Default Value of 'return' Statement According to the Function Signature

[Larry Garfield]

On Thu, Mar 11, 2021, at 6:10 AM, Hamza Ahmad wrote:
> Hi Victor,
> 
> It does not contradict because it does not cover two different aspects. 
> First, return types specify the types of to be returned values. Second, 
> this request proposes a shorthand technique to avoid writing a single 
> line code multiple times. Third, it is similar to default argument 
> values that are also typed.
> 
> Cheers!

Greetings.  First, please don't top post.  This is a bottom-posting list.

As to your proposal, it's a bit hard to follow because it sounds like you're 
suggesting an implicit "return of nothing" built on union types, when based on 
your follow ups what I think you're suggesting is something more like this:

function foo(int $bar = 4): int = 0 {
  if (is_even($bar)) {
return; // Implicitly returns 0
  }
  return $bar * 2;
}

That is, allowing a default return value.  Union types aren't part of the 
picture.

I can see how you got to the idea, but honestly I am not a fan.  Primarily... 
I've never run into the situation you describe where multiple early-returns 
would have the same value.  Perhaps it's just because in those cases I end up 
combining the conditionals with an ||, but I don't see the problem you 
describe.  Different code paths should result in different results, or else why 
are they different code paths?

So, code that's doing that I'd be suspicious of to begin with.

Even if you did end up in such a situation, since you're dealing with a static 
value, setting the default internally within the function is trivial:

function foo(int $bar = 4): int {
  $default = 0;
  if (is_even($bar)) {
return $default;
  }
  return $bar * 2;
}

So basically, in the few cases where this isn't a code smell, it's unnecessary.

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] 回复：Re: [PHP-DEV] [VOTE] Fibers

[韩天峰]

Hi,
I am come from Chinese, we may have some cultural differences, and there may be 
some difficulties in communication. I try to express my opinion.
To be precise, the fiber can only be used for amphp and reactphp or other 
event-driven asynchronous IO frameworks developed using php.The RFC does 
not mention how an extension uses fiber.
Fiber is not like threads or processes of operating system. It is not parallel, 
nor is it concurrent. This requires an event-driven scheduler to have practical 
value.Currently php does not have event-driven support. So normal web 
developers don’t know how to use fiber.It is for developers of 
asynchronous io programming.
I just suggest first to provide a PECL extension like ext-event/ext-libevent, 
no need to be integrated into php now.Swoole is also provided to users as 
a PECL extension.




--原始邮件--
发件人: "Peter Stalman"; 
发送时间: 2021年3月11日(星期四) 下午2:37
收件人: "韩天峰"; 
抄送: "Aaron Piotrowski"; "php internals"; 
主题: Re: [PHP-DEV] [VOTE] Fibers



OnWed.,Mar.10,2021,02:16韩天峰,

Re: [PHP-DEV] [RFC] [Discussion] Adding return types to internal methods

[Máté Kocsis]

Hi Nicolas and Claude,

First of all, thanks for your comments! Let me answer them one by one:

1.) A few other people off-list also shared their negative feelings about
the E_STRICT. So I'm ok to use E_DEPRECATED instead.
Now that I implemented the suppressing mechanism, I think using a separate
error type is not needed anymore that much.

2.) Unifying the TentativeReturnType and SuppressReturnTypeNotice
attributes is an interesting idea, and I would love to get
rid of the latter one. Although, my concern is that doing so would
eliminate the possibility for an overriding method to declare
its own native return types (it's possible that they've already defined
return types): so any child class could literally define
return types at its own will, while it was not possible to do before. I'm
eager to listen to any solution that would address my concerns. :)

3.) I'm not sure you noticed in the PR, but in fact, I also implemented
the TentativeReturnType attribute. Currently, it can be used
as below when DateTime::modify() is overridden to return the ?DateTime type:

class MyDateTime extends DateTime
{
#[TentativeReturnType]
public function modify(string $modifier): ?DateTime { return null; }
}

How does this syntax look like for you?

Compared to your proposal, the main difference is that the attribute
doesn't itself store any type information, but it's done among the
function information as normally. In my opinion, the current implementation
has multiple advantages over the one you proposed:
- As far as I can tell, it would be *very* cumbersome to parse and validate
type information from strings, rather than reusing the
capabilities we already have. But I'd be happy to be corrected if I'm wrong.
- Apart from the compiler itself, I think parsing type info is more
straightforward as currently implemented for users as well as any tooling
- We should also think about people who already declared return types for
overriding methods. I don't see any good reason why they
should repeat this information in the attribute.
- I'm also not sure how the attribute could be used to retrieve the
tentative type? Should it return a ReflectionType? Returning
just the string representation seems like subideal for me.

4.) Claude, I think you make a good point! So non-private, untyped
properties could be converted to typed properties a little bit more
gradually
if we made this "tentative" type mechanism available for properties as
well. Coincidentally, I recently came up with the idea that I'd like to fix
type
issues with internal class properties (e.g. lots of them don't respect the
strict_types directive), and I also thought about migrating them to typed
properties for PHP 9.0. All in all, I don't want to include properties in
the current proposal, but I'd probably work on it next time.

Regards:
Máté


Claude Pache  ezt írta (időpont: 2021. márc. 8., H,
16:19):

>
> > Le 6 mars 2021 à 23:56, Máté Kocsis  a écrit :
> >
> > Hi Internals,
> >
> > I've just finished the first iteration of the RFC (
> > https://wiki.php.net/rfc/internal_method_return_types) as well as the
> > implementation based on the feedback Nikita and Nicolas provided. Thus,
> I'd
> > like to start the discussion phase.
> >
> > Regards:
> > Máté
>
> Hi,
>
> Two remarks:
>
> (1) The RFC is about return type of non-final methods. The same issue
> might arise for typed properties, whose type are supposed to be invariant
> under inheritance; although it is admittedly rarely useful to redeclare
> them in the subclass. Should typed properties be handled in the same way,
> or should we simply recommend to not redeclare properties?
>
> (2) Nicolas Grekas has beaten about E_STRICT (E_DEPRECATED is fine in this
> case). I’m just adding this: By reintroducing E_STRICT you are effectively
> reverting the [Reclassify E_STRICT notices] RFC, whose motivation was to
> “simplify our error model and resolve the currently unclear role of strict
> standards notices”. Thus, you should propose a clear role of those
> resurrected E_STRICT notices, that justifies the complication of the error
> model.
>
> [Reclassify E_STRICT notices]:
> https://wiki.php.net/rfc/reclassify_e_strict
>
> —Claude

Re: [PHP-DEV] [RFC] noreturn type

[Brent Roose]

Hi Peter and internals

> On 11 Mar 2021, at 07:51, Peter Stalman  wrote:
> 
> On Wed., Mar. 10, 2021, 11:22 Matthew Brown, 
> wrote:
> 
>> If a significant number agree I can add a secondary vote on noreturn vs
>> never, but never introduces more of a BC risk.
>> 
> 
> Hi Matt,
> 
> I like this RFC, but I'd like to see the RFC cover if any other languages
> have a similar return type.

What made it clear to me was this:

returning nothing (void) isn't the same as not returning (noreturn, eg throw or 
exit).

Having read that somewhere on Twitter made it easier for me to reason about. 
It's a useful feature in the static analysis world.

> 
> The definition of `void` is that it has no return value, so I too agree
> that the keyword `noreturn` is too close in meaning to `void`.
> 
> I'd also like to throw the word `deadend` or something similar into the
> ring, to make things a bit clearer.
> 
> Thanks,
> Peter

Kind regards
Brent

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

RE: [PHP-DEV] Honour the Default Value of 'return' Statement According to the Function Signature

[Hamza Ahmad]

Hi Victor,

It does not contradict because it does not cover two different aspects. First, 
return types specify the types of to be returned values. Second, this request 
proposes a shorthand technique to avoid writing a single line code multiple 
times. Third, it is similar to default argument values that are also typed.

Cheers!

 

From: Victor Bolshov  
Sent: Thursday, March 11, 2021 3:00 PM
To: Hamza Ahmad 
Cc: Rowan Tommins ; internals@lists.php.net
Subject: Re: [PHP-DEV] Honour the Default Value of 'return' Statement According 
to the Function Signature

 

IMO this feature would contradict with the Single Responsibility Principle. 
Type hints are for type hinting, not for value hinting. Cheers.

 

Sent from Mailspring 

 , the best free email app for work

On Mar 11 2021, at 10:51 am, Hamza Ahmad  wrote:

Hi Rowan,

Thanks for the response. Luckily, you razed the question that I thought about 
after posting the first request.

My idea develops on respecting both return type hints and union types. The 
current implementation of empty return does not respect the function signature. 
As I have mentioned in the first message that empty return returns null 
regardless of the return type set, I propose that an empty return may return 
the defaults of types i.e. an empty string if the type is string, an empty 
array if the type is array, zero if the type is int etcetera. I have also noted 
that in a void typed function, an empty return may return nothing and just end 
the execution.

The current implementation of empty return is only favourable for mixed type. 
In other words, when the return type is mixed, an empty return may return null. 
Otherwise, it should respect the declared return type.

After the release of union types, there emerges a question regarding the 
selection of default return value. To solve this problem, the type on the very 
right side will be used.

Now, I come to your question, Rowan. As of today, only false and null literals 
are supported. If both assist in error handling, why does empty return always 
returns null?

I tested this code on shell.

var_dump($a=(function():string|false{return;})());

It produced:

Fatal error: A function with return type must return a value in php shell code 
on line 1.

Here comes the inconsistency. To resolve the problem, I suggest to respect the 
literals first. If literals are not found, respect the first type on the right 
side.

Moreover, only two standalone literals, false and null, will be supported. 
Otherwise, the literal should be one of the types specified. If multiple 
literals are specified, it will throw an error of multiple literals. The 
literal can be a simple literal, such as, "unknown" 0, and a constant 
expression, like self :: MSG_UNKNOWN. It will help maintain the multi-language 
scripts.

I hope I have been able to make my stance clear.

Best

Hamza Ahmad

 

-Original Message-

From: Rowan Tommins 

Sent: Thursday, March 11, 2021 1:45 PM

To: internals@lists.php.net

Subject: Re: [PHP-DEV] Honour the Default Value of 'return' Statement According 
to the Function Signature

 

On 11 March 2021 03:37:52 GMT, office.hamzaah...@gmail.com wrote:

>function get_nationality_string(int $country_code) : string | "unknown"

>{

> return;

>};

 

If I understand you correctly, your idea is that the "return;" here would be 
treated automatically as "return 'unknown';" I think that's an interesting 
idea, although I can't immediately think of a situation where I'd use it.

 

My main concerns are with the syntax:

 

- Firstly, specific literals aren't currently allowed in return types, and 
allowing them would have other implications. Three exception is "false", which 
is allowed because of its common use as an error code, including in many 
internal functions.

- Secondly, it could be ambiguous which is intended to be the default value, if 
the return type was something like int|"yes"|"no"

 

Perhaps the default return value would need to be specified separately from the 
return type somehow?

 

Regards,

Hi Hamza,

 

Welcome to the list, and thanks for sharing this idea.

 

--

Rowan Tommins

[IMSoP]

 

--

PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: 
https://www.php.net/unsub.php

 

--

PHP Internals - PHP Runtime Development Mailing List

To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] noreturn type

[Marco Pivetta]

Hey Aleksander,

On Thu, Mar 11, 2021 at 8:25 AM Aleksander Machniak  wrote:

> On 10.03.2021 20:28, Ben Ramsey wrote:
> >> I don't like that type covariance would be allowed. Why such an
> >> exception to the rules?
> >
> > It’s not an exception. Returns are covariant. Parameters are
> > contravariant. Since `noreturn` is a subtype of all other types, it
> > behaves as expected.
>
> I see it's a subtype, I don't get why. Wouldn't it be better to be a
> separate type so return type covariance is not allowed (as it is with
> void)? Was it a design decision or a side product of the implementation?
>

`noreturn` is what's called the "bottom type", and it's a subtype of all
types.
It can sound counter-intuitive, but it is true that all methods in a
subclass can be re-implemented with the bottom type as their return type
(instead of their original one), and the system is still sound from a type
perspective.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Re: [PHP-DEV] Honour the Default Value of 'return' Statement According to the Function Signature

[Victor Bolshov]

IMO this feature would contradict with the Single Responsibility Principle. 
Type hints are for type hinting, not for value hinting. Cheers.

Sent from Mailspring 
(https://link.getmailspring.com/link/4d67851f-de69-45d9-9db1-54b16845e...@getmailspring.com/0?redirect=https%3A%2F%2Fgetmailspring.com%2F=aW50ZXJuYWxzQGxpc3RzLnBocC5uZXQ%3D),
 the best free email app for work
On Mar 11 2021, at 10:51 am, Hamza Ahmad  wrote:
> Hi Rowan,
> Thanks for the response. Luckily, you razed the question that I thought about 
> after posting the first request.
> My idea develops on respecting both return type hints and union types. The 
> current implementation of empty return does not respect the function 
> signature. As I have mentioned in the first message that empty return returns 
> null regardless of the return type set, I propose that an empty return may 
> return the defaults of types i.e. an empty string if the type is string, an 
> empty array if the type is array, zero if the type is int etcetera. I have 
> also noted that in a void typed function, an empty return may return nothing 
> and just end the execution.
> The current implementation of empty return is only favourable for mixed type. 
> In other words, when the return type is mixed, an empty return may return 
> null. Otherwise, it should respect the declared return type.
> After the release of union types, there emerges a question regarding the 
> selection of default return value. To solve this problem, the type on the 
> very right side will be used.
> Now, I come to your question, Rowan. As of today, only false and null 
> literals are supported. If both assist in error handling, why does empty 
> return always returns null?
> I tested this code on shell.
> var_dump($a=(function():string|false{return;})());
> It produced:
> Fatal error: A function with return type must return a value in php shell 
> code on line 1.
> Here comes the inconsistency. To resolve the problem, I suggest to respect 
> the literals first. If literals are not found, respect the first type on the 
> right side.
> Moreover, only two standalone literals, false and null, will be supported. 
> Otherwise, the literal should be one of the types specified. If multiple 
> literals are specified, it will throw an error of multiple literals. The 
> literal can be a simple literal, such as, "unknown" 0, and a constant 
> expression, like self :: MSG_UNKNOWN. It will help maintain the 
> multi-language scripts.
> I hope I have been able to make my stance clear.
> Best
> Hamza Ahmad
>
> -Original Message-
> From: Rowan Tommins 
> Sent: Thursday, March 11, 2021 1:45 PM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] Honour the Default Value of 'return' Statement 
> According to the Function Signature
>
> On 11 March 2021 03:37:52 GMT, office.hamzaah...@gmail.com wrote:
> > >function get_nationality_string(int $country_code) : string | "unknown"
> >{
> > return;
> >};
>
> If I understand you correctly, your idea is that the "return;" here would be 
> treated automatically as "return 'unknown';" I think that's an interesting 
> idea, although I can't immediately think of a situation where I'd use it.
> My main concerns are with the syntax:
> - Firstly, specific literals aren't currently allowed in return types, and 
> allowing them would have other implications. Three exception is "false", 
> which is allowed because of its common use as an error code, including in 
> many internal functions.
> - Secondly, it could be ambiguous which is intended to be the default value, 
> if the return type was something like int|"yes"|"no"
>
> Perhaps the default return value would need to be specified separately from 
> the return type somehow?
> Regards,
> Hi Hamza,
>
> Welcome to the list, and thanks for sharing this idea.
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: 
> https://www.php.net/unsub.php
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

RE: [PHP-DEV] Honour the Default Value of 'return' Statement According to the Function Signature

[Hamza Ahmad]

Hi Rowan,
Thanks for the response. Luckily, you razed the question that I thought about 
after posting the first request.
My idea develops on respecting both return type hints and union types. The 
current implementation of empty return does not respect the function signature. 
As I have mentioned in the first message that empty return returns null 
regardless of the return type set, I propose that an empty return may return 
the defaults of types i.e. an empty string if the type is string, an empty 
array if the type is array, zero if the type is int etcetera. I have also noted 
that in a void typed function, an empty return may return nothing and just end 
the execution.
The current implementation of empty return is only favourable for mixed type. 
In other words, when the return type is mixed, an empty return may return null. 
Otherwise, it should respect the declared return type.
After the release of union types, there emerges a question regarding the 
selection of default return value. To solve this problem, the type on the very 
right side will be used.
Now, I come to your question, Rowan. As of today, only false and null literals 
are supported. If both assist in error handling, why does empty return always 
returns null?
I tested this code on shell.
var_dump($a=(function():string|false{return;})());
It produced:
Fatal error: A function with return type must return a value in php shell code 
on line 1.
Here comes the inconsistency. To resolve the problem, I suggest to respect the 
literals first. If literals are not found, respect the first type on the right 
side.
Moreover, only two standalone literals, false and null,  will be supported. 
Otherwise, the literal should be one of the types specified. If multiple 
literals are specified, it will throw an error of multiple literals. The 
literal can be a simple literal, such as, "unknown" 0, and a constant 
expression, like self :: MSG_UNKNOWN. It will help maintain the multi-language 
scripts.
I hope I have been able to make my stance clear.
Best
Hamza Ahmad

-Original Message-
From: Rowan Tommins  
Sent: Thursday, March 11, 2021 1:45 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Honour the Default Value of 'return' Statement According 
to the Function Signature

On 11 March 2021 03:37:52 GMT, office.hamzaah...@gmail.com wrote:
>function get_nationality_string(int $country_code) : string | "unknown"
>{
>   return;
>};

If I understand you correctly, your idea is that the "return;" here would be 
treated automatically as "return 'unknown';" I think that's an interesting 
idea, although I can't immediately think of a situation where I'd use it.

My main concerns are with the syntax:

- Firstly, specific literals aren't currently allowed in return types, and 
allowing them would have other implications. Three exception is "false", which 
is allowed because of its common use as an error code, including in many 
internal functions.
- Secondly, it could be ambiguous which is intended to be the default value, if 
the return type was something like int|"yes"|"no"

Perhaps the default return value would need to be specified separately from the 
return type somehow?

Regards,
Hi Hamza,

Welcome to the list, and thanks for sharing this idea.

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: 
https://www.php.net/unsub.php

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: Recent changes to opcache cause crashes

[Derick Rethans]

Hi Dmitry,

I can confirm that it works locally again too now.

cheers,
Derick


On Wed, 10 Mar 2021, Dmitry Stogov wrote:

> This is fixed in master.
> 
> Thanks. Dmitry.
> 
> On Fri, Mar 5, 2021 at 4:43 PM Dennis Birkholz 
> wrote:
> 
> > Hello,
> >
> > I was also able to reproduce the error.
> >
> > I used the latest available "daily" cloud image for Debian Buster and
> > created a small recipe to reproduce. Hopefully this helps in finding the
> > problem.
> >
> > Greets
> > Dennis
> >
> >
> > wget
> > "
> > https://cloud.debian.org/images/cloud/buster/20210208-542/debian-10-nocloud-amd64-20210208-542.tar.xz
> > "
> > tar -xvf "debian-10-nocloud-amd64-20210208-542.tar.xz"
> >
> > # Resized the image, 2GB is to small
> > dd if=/dev/zero bs=1M count=1 seek=20479 of=disk.raw
> > echo ", +" | /sbin/sfdisk -N 1 disk.raw
> > sudo losetup -f --show disk.raw
> > sudo partprobe /dev/loop0
> > sudo e2fsck -f /dev/loop0p1
> > sudo resize2fs /dev/loop0p1
> > sudo losetup -d /dev/loop0
> >
> > # create and start VM, e.g. with virt-manager
> >
> > # Inside VM
> > # Generate ssh host keys
> > dpkg-reconfigure openssh-server
> > # Change PermitRootLogin, PasswordAuthentication and
> > PermitEmptyPasswords to yes to login without password/key
> > systemctl restart sshd.service
> >
> > apt install git autoconf make gcc g++ pkg-config bison re2c libssl-dev
> > libxml2-dev libsqlite3-dev zlib1g-dev libbz2-dev libcurl4-openssl-dev
> > libpng-dev libjpeg-dev libonig-dev libreadline-dev libsodium-dev
> > libxslt1-dev libzip-dev libffi-dev
> >
> > git clone https://github.com/php/php-src
> > cd php-src
> > ./buildconf
> > ./configure  '--prefix=/usr/local/php/master' '--enable-debug'
> > '--with-gettext' '--with-gd' '--enable-gd' '--with-jpeg'
> > '--without-freetype' '--with-jpeg-dir=/usr' '--without-freetype-dir'
> > '--with-mysql=mysqlnd' '--enable-bcmath' '--with-readline'
> > '--with-openssl' '--without-esmtp' '--with-curl' '--with-sodium'
> > '--with-ffi' '--with-mysqli' '--enable-pcntl' '--enable-sockets'
> > '--enable-zip' '--with-zip' '--enable-memory-limit' '--with-mcrypt'
> > '--with-libxml' '--enable-libxml' '--with-iconv' '--enable-wddx'
> > '--enable-calendar' '--with-sqlite3' '--enable-spl' '--enable-pdo'
> > '--with-pdo-mysql' '--with-pdo-sqlite' '--with-ctype' '--with-bz2'
> > '--enable-mbstring' '--with-mime-magic' '--with-xmlrpc' '--with-zlib'
> > '--disable-zend-memory-manager' '--with-esmtp' '--with-xsl'
> > '--enable-exif' '--enable-soap' '--enable-ftp' '--enable-intl'
> > '--enable-opcache' '--enable-fpm' '--enable-fileinfo' '--with-pear'
> > make && make install
> >
> > cd ~
> > wget
> > "
> > https://derickrethans.nl/files/dump/xdebug_var_dump_typed_properties-text.php.txt
> > "
> > -O "xdebug_var_dump_typed_properties-text.php"
> > /usr/local/php/master/bin/php -n -dzend_extension=opcache -d
> > "opcache.enable=1" -d "opcache.enable_cli=1" -d
> > "opcache.optimization_level=-1" -f
> > xdebug_var_dump_typed_properties-text.php
> >
> >
> > Am 04.03.21 um 19:14 schrieb Dmitry Stogov:
> > > I suppose, something is wrong with your build.
> > > This code works fine for me.
> > > Please, try full rebuild.
> > >
> > > Thanks. Dmitry.
> > >
> > > On Thu, Mar 4, 2021 at 9:00 PM Derick Rethans  wrote:
> > >
> > >> Hi,
> > >>
> > >> turns out that this test fails even without Xdebug even loaded, so it's
> > >> not something on my side :-)
> > >>
> > >> Just run it as:
> > >>
> > >> wget
> > >>
> > https://derickrethans.nl/files/dump/xdebug_var_dump_typed_properties-text.php.txt
> > >> -O xdebug_var_dump_typed_properties-text.php
> > >> php -n -dzend_extension=opcache -d "opcache.enable=1" -d
> > >> "opcache.enable_cli=1" -d "opcache.optimization_level=-1" -f
> > >> xdebug_var_dump_typed_properties-text.php
> > >>
> > >> Result:
> > >>
> > >> php: /home/derick/dev/php/php-src.git/ext/opcache/zend_persist.c:327:
> > >> zend_accel_get_type_map_ptr: Assertion `ret > 2' failed.
> > >> Aborted
> > >>
> > >>
> > >> cheers,
> > >> Derick
> > >>
> > >>
> > >
> >
> >
> 

-- 
PHP 7.4 Release Manager
Host of PHP Internals News: https://phpinternals.news
Like Xdebug? Consider supporting me: https://xdebug.org/support
https://derickrethans.nl | https://xdebug.org | https://dram.io
twitter: @derickr and @xdebug

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Honour the Default Value of 'return' Statement According to the Function Signature

[Rowan Tommins]

On 11 March 2021 03:37:52 GMT, office.hamzaah...@gmail.com wrote:
>function get_nationality_string(int $country_code) : string | "unknown"
>{
>   return;
>};

If I understand you correctly, your idea is that the "return;" here would be 
treated automatically as "return 'unknown';" I think that's an interesting 
idea, although I can't immediately think of a situation where I'd use it.

My main concerns are with the syntax:

- Firstly, specific literals aren't currently allowed in return types, and 
allowing them would have other implications. Three exception is "false", which 
is allowed because of its common use as an error code, including in many 
internal functions.
- Secondly, it could be ambiguous which is intended to be the default value, if 
the return type was something like int|"yes"|"no"

Perhaps the default return value would need to be specified separately from the 
return type somehow?

Regards,
Hi Hamza,

Welcome to the list, and thanks for sharing this idea.

-- 
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] noreturn type

[Sebastian Bergmann]

Am 10.03.2021 um 19:06 schrieb Matthew Brown:

Ondřej Mirtes and I present an RFC for the noreturn type:
https://wiki.php.net/rfc/noreturn_type


Thank you, Ondřej and Matt, for bringing this up. Makes sense to me, +1.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] noreturn type

[Ilija Tovilo]

Hi Aleksander

> I see it's a subtype, I don't get why. Wouldn't it be better to be a
> separate type so return type covariance is not allowed (as it is with
> void)? Was it a design decision or a side product of the implementation?

This is a fairly common technique. For example, this is from the
TypeScript handbook:

https://www.typescriptlang.org/docs/handbook/basic-types.html#never

> The never type is a subtype of, and assignable to, every type; however, no 
> type is a subtype of, or assignable to, never (except never itself). Even any 
> isn’t assignable to never.

Imagine the following scenario:

function foo(callable(): int $computeSomething) {
$magicNumber = $computeSomething();
}

function bar(): noreturn {
throw new Exception('bar');
}

// Is completely type-safe as $magicNumber will never be assigned
foo('bar');

// Without noreturn being a bottom type you'd have to do this
foo(function(): int {
bar();
});

We don't have callable types yet but it's common in other languages.
The point is that, since noreturn will throw, terminate or never end,
$magicNumber will never be assigned. This means effectively the return
type of any function can be safely substituted with noreturn.

The other benefit is that you can accurately typehint an overridden method.

class Foo {
function baz(): int {
return 42;
}
}

class Bar extends Foo {
function baz(): noreturn {
throw new Exception();
}
}

$bar = new Bar();
$bar->baz(); // IDE will know this always terminates
qux(); // Dead code

Not every language allows this but it does make sense semantically.
It's not a deal breaker if we don't have it but given that the
implementation is fairly simple I don't see why we wouldn't.

Ilija

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php