Re: [PHP-DEV] [VOTE] Object scoped RNG implementation

[Go Kudo]

Hi Morrison.

> Sorry if I missed an optional "intent to vote soon" thread.

I thought I had announced it here, but I did not indicate the specific
dates. I apologize for that.
https://externals.io/message/113720

> simply based on the fact that namespaced things are going
into`ext/standard`.

Yes, I feel that the use of namespaces is an area that needs to be
carefully discussed.

The goal of this RFC is just to get such a feature into core, and we are
not particularly concerned about namespaces. (In other words, we think it's
fine to change RNG\RNGInterface to RNGInterface and RNG\XorShift128Plus to
XorShift128PlusRNG and not use namespaces.)

As per the RFC, we believe this feature is necessary for approaches like
Fiber and Swoole, which have more complex execution order and state
management.

What if you have a problem with this feature being implemented in
`ext/standard`? I think this is unavoidable since `shuffle()`,
`array_rand()`, and `str_suffle()` are implemented in `ext/standard`.

The original RFC suggested quarantining them as `ext/rng` to avoid this
(PECL orng is mostly based on the original idea), but the global state
dependent `shuffle()`, `array_rand()`, and `str_shuffle()` are implemented
in `ext/standard`. ext/standard` are implemented and not deprecated, the
possibility of unintentionally writing state-dependent code increases in
the future.

Let me know what you think.

2021年4月2日(金) 4:19 Levi Morrison :

> On Wed, Mar 31, 2021 at 10:39 PM Go Kudo  wrote:
> >
> > Hello everyone.
> >
> > Object scoped RNG RFC vote is now open.
> > https://wiki.php.net/rfc/object_scope_prng
> >
> > The deadline for voting is April 15.
> >
> > Previous discussions can be viewed below.
> >
> > https://externals.io/message/112765
> > https://externals.io/message/112819
> > https://externals.io/message/113720
> >
> > Regards,
> > Go Kudo
>
> Sorry if I missed an optional "intent to vote soon" thread. I voted no
> simply based on the fact that namespaced things are going into
> `ext/standard`. We have an open RFC discussion on this issue, which
> has had discussion as recently as 10 days ago. I cannot vote "yes" on
> anything involved with namespaces in this context in good conscience.
>
> At the same time, we shouldn't block things indefinitely.
>

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

[Aaron Piotrowski]

> On Apr 1, 2021, at 2:03 PM, Levi Morrison via internals 
>  wrote:
> 
> I do not care which name is chosen, but if we are going to have this
> sort of thing in the language, it ought to be a bottom type, not an
> attribute.
> 

You make an excellent point Levi. I initially chose `noreturn` simply because I 
was familiar with the name from C and didn't have a strong opinion. However, I 
agree that `noreturn` is a poor choice for reuse as a bottom type, so I changed 
my vote to `never`.

Cheers,
Aaron Piotrowski

Re: [PHP-DEV] Changes to Git commit workflow

[Nikita Popov]

On Thu, Apr 1, 2021 at 10:17 PM CHU Zhaowei  wrote:

> Hi Nikita,
>
> Can I check with you if the hook integrating with bugs.php.net still
> works? I just committed a bug fix on doc-zh repo, and the bug report has
> been updated. Thanks.
>
> Regards,
> CHU Zhaowei
>

This issue is probably fixed by
https://github.com/php/web-master/commit/d0cac5411f97ec9df5995a632c20da770a77dedb
.

Nikita

-Original Message-
> From: Nikita Popov 
> Sent: Monday, March 29, 2021 6:52 AM
> To: PHP internals ; PHP Doc Mailing List <
> php...@lists.php.net>
> Subject: [PHP-DEV] Changes to Git commit workflow
>
> Hi everyone,
>
> Yesterday (2021-03-28) two malicious commits were pushed to the php-src
> repo [1] from the names of Rasmus Lerdorf and myself. We don't yet know how
> exactly this happened, but everything points towards a compromise of the
> git.php.net server (rather than a compromise of an individual git
> account).
>
> While investigation is still underway, we have decided that maintaining
> our own git infrastructure is an unnecessary security risk, and that we
> will discontinue the git.php.net server. Instead, the repositories on
> GitHub, which were previously only mirrors, will become canonical. This
> means that changes should be pushed directly to GitHub rather than to
> git.php.net.
>
> While previously write access to repositories was handled through our
> home-grown karma system, you will now need to be part of the php
> organization on GitHub. If you are not part of the organization yet, or
> don't have access to a repository you should have access to, contact me at
> ni...@php.net with your php.net and GitHub account names, as well as the
> permissions you're currently missing. Membership in the organization
> requires 2FA to be enabled.
>
> This change also means that it is now possible to merge pull requests
> directly from the GitHub web interface.
>
> We're reviewing the repositories for any corruption beyond the two
> referenced commits. Please contact secur...@php.net if you notice
> anything.
>
> Regards,
> Nikita
>
> [1]:
>
> https://github.com/php/php-src/commit/c730aa26bd52829a49f2ad284b181b7e82a68d7d
> and
>
> https://github.com/php/php-src/commit/2b0f239b211c7544ebc7a4cd2c977a5b7a11ed8a
>
>
>
>

RE: [PHP-DEV] Changes to Git commit workflow

[CHU Zhaowei]

Hi Nikita,

Can I check with you if the hook integrating with bugs.php.net still works? I 
just committed a bug fix on doc-zh repo, and the bug report has been updated. 
Thanks.

Regards,
CHU Zhaowei

-Original Message-
From: Nikita Popov  
Sent: Monday, March 29, 2021 6:52 AM
To: PHP internals ; PHP Doc Mailing List 

Subject: [PHP-DEV] Changes to Git commit workflow

Hi everyone,

Yesterday (2021-03-28) two malicious commits were pushed to the php-src repo 
[1] from the names of Rasmus Lerdorf and myself. We don't yet know how exactly 
this happened, but everything points towards a compromise of the git.php.net 
server (rather than a compromise of an individual git account).

While investigation is still underway, we have decided that maintaining our own 
git infrastructure is an unnecessary security risk, and that we will 
discontinue the git.php.net server. Instead, the repositories on GitHub, which 
were previously only mirrors, will become canonical. This means that changes 
should be pushed directly to GitHub rather than to git.php.net.

While previously write access to repositories was handled through our 
home-grown karma system, you will now need to be part of the php organization 
on GitHub. If you are not part of the organization yet, or don't have access to 
a repository you should have access to, contact me at ni...@php.net with your 
php.net and GitHub account names, as well as the permissions you're currently 
missing. Membership in the organization requires 2FA to be enabled.

This change also means that it is now possible to merge pull requests directly 
from the GitHub web interface.

We're reviewing the repositories for any corruption beyond the two referenced 
commits. Please contact secur...@php.net if you notice anything.

Regards,
Nikita

[1]:
https://github.com/php/php-src/commit/c730aa26bd52829a49f2ad284b181b7e82a68d7d
and
https://github.com/php/php-src/commit/2b0f239b211c7544ebc7a4cd2c977a5b7a11ed8a

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

Re: [PHP-DEV] [VOTE] Object scoped RNG implementation

[Levi Morrison via internals]

On Wed, Mar 31, 2021 at 10:39 PM Go Kudo  wrote:
>
> Hello everyone.
>
> Object scoped RNG RFC vote is now open.
> https://wiki.php.net/rfc/object_scope_prng
>
> The deadline for voting is April 15.
>
> Previous discussions can be viewed below.
>
> https://externals.io/message/112765
> https://externals.io/message/112819
> https://externals.io/message/113720
>
> Regards,
> Go Kudo

Sorry if I missed an optional "intent to vote soon" thread. I voted no
simply based on the fact that namespaced things are going into
`ext/standard`. We have an open RFC discussion on this issue, which
has had discussion as recently as 10 days ago. I cannot vote "yes" on
anything involved with namespaces in this context in good conscience.

At the same time, we shouldn't block things indefinitely.

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

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

[Levi Morrison via internals]

On Thu, Apr 1, 2021 at 6:59 AM Matthew Brown  wrote:
>
> On Thu, 1 Apr 2021 at 04:56, Benjamin Eberlei  wrote:
>
> > This RFC is using the declaration of the return type, to specify that it
> > never returns. As such noreturn or never is a keyword a long the lines of
> > public or final, but it is not a return type.
> >
> > I don't think the argument for potential optimizations in Opcache to
> > eliminate dead code or allow IDEs to hint at dead code are valuable enough
> > to justify this change.
> >
>
> By this argument "void" should also be an attribute – there's no reason to
> hint a value that's not being returned.
>
> You'd write functions like
>
> [\Void]
> function foo() { ... }
>
> But we don't do that, because the wider programming language community has
> agreed that "void" is a type, and at compile-time PHP's engine can ensure
> that "void" functions do not return a value.

For what it is worth, it does return a value `null`, which has a type.
Using "void" is outright wrong, a lie told because "we" voted it this
way. Few people seemed to care when I brought this up, but null makes
sense with union types, covariance, etc, which we now have. I'm still
slightly bitter about this, in case you cannot tell.

The [void RFC][1] said:
> There's no precedent for it and the name doesn't seem to have been an issue 
> until now.

This was disingenuous, as it disregards Swift and Rust, both of which
use a unit type; they just call it () instead of null. These languages
are held in high regard as far as mainstream programming languages go,
but instead we voted to repeat the mistakes of C and company. I
believe Python's PEP 484 for Type Hints was available at this time,
and it uses None when no value is explicitly returned just like PHP
does with null.

But, we decided to do it the wrong way a la C. Let's please not repeat
this mistake. For the record, in C this is an attribute (and
non-standard at that!), not a return type, so this is a particularly
apt comparison.

Please, let's _accurately_ follow type theory and use a bottom type.
According to the [data in Wikipedia][2], the most common names for the
bottom type are:

 1. `never`, used by Elm and Typescript. Note that in Rust the bottom
type is `!` but spelled out in docs as "never".
 2. `nothing`, used by Kotlin, Ceylon, and Scala.

I do not care which name is chosen, but if we are going to have this
sort of thing in the language, it ought to be a bottom type, not an
attribute.

  [1]: https://wiki.php.net/rfc/void_return_type#why_call_it_void_and_not_null
  [2]: https://en.wikipedia.org/wiki/Bottom_type#In_programming_languages

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

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

[Ondřej Mirtes]

On 1. 4. 2021 19:24:35, Bruce Weirdan  wrote:

> Since `throw` is an expression (since PHP 8.0,
> https://wiki.php.net/rfc/throw_expression), it must have a type for its
> result,
> as any expression has a type. And it's result is exactly `noreturn` (or
> `never`, as this option seems to be preferred
> judging by current vote results), because `throw` never returns.
>
> It's quite natural to extend that to function calls that never return as
> well. And then it makes sense to declare that type
> as a part of function signature like you can do with other types.
>
> --
>  Best regards,
>  Bruce Weirdan mailto:
> weir...@gmail.com
>

Yes, this works very well in the typesystem. For example if we define the
type of the match expression as a union of all its arms, then the arm that
always throws or contains exit() has the noreturn/never type, which is
thrown away in a union (int|string|never can be normalized to int|string).

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

[Andreas Hennings]

On Thu, 1 Apr 2021 at 15:05, Matthew Brown  wrote:
>
> On Tue, 30 Mar 2021 at 13:51, Ilija Tovilo  wrote:
>
> > Hi Matthew
> >
> > > I like the proposal. I also support the covariance.
> > >
> > > One question though.
> > > The RFC mentions possible future use of "nothing" as a bottom type for
> > > parameters in generics. This makes a lot of sense to me. Even without
> > > generics, it could be used for parameters in abstract methods.
> > >
> > > So why not already introduce "nothing" as the universal bottom type, and
> > > use it instead of "noreturn"?
> > > Can "noreturn" do anything that "nothing" can't?
> >
> > I'm also a little confused by this statement. The exact wording from the
> > RFC is:
> >
> > > Arguments for never: ... It's a full-fledged type, rather than a keyword
> > used in a specific situation. A far-in-the-future generics proposal could
> > use never as a placeholder inside contravariant generic types.
> >
> > From what I understand, in Hack noreturn and never are both
> > full-fledged types. Nothing is a bottom type while noreturn is not.
> > Since in your proposal noreturn would also be a bottom type there's no
> > reason why it couldn't be used in covariant or contravariant generic
> > parameters.
> >
> > Please correct me if I'm missing something.
> >
> > Ilija
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php
> >
> >
> In Hack it's a bit confusing. I think the Hack team ultimately decided that
> "nothing" was a better name for the bottom type than "noreturn", and
> confusingly introduced one while the other was still active.
>
> They have a long-term plan to deprecate "noreturn" in favour of "nothing"
> and stop supporting the former name, though it's unclear when that might
> happen.

More reason for us to avoid this mistake, and introduce a name and
concept that takes into account "bottom types", or not?
We should decide now if we want to use the same keyword for
everything, or if a bottom type should be distinct from a no-return
behavior.

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

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

[Bruce Weirdan]

On Thu, Apr 1, 2021 at 6:07 PM Benjamin Eberlei  wrote:

>
> ```php
> if (!isset($user)) {
>throw new NotFoundException();
> }
> ```
>

Since `throw` is an expression (since PHP 8.0,
https://wiki.php.net/rfc/throw_expression), it must have a type for its
result,
as any expression has a type. And it's result is exactly `noreturn` (or
`never`, as this option seems to be preferred
judging by current vote results), because `throw` never returns.

It's quite natural to extend that to function calls that never return as
well. And then it makes sense to declare that type
as a part of function signature like you can do with other types.

-- 
  Best regards,
  Bruce Weirdan mailto:
weir...@gmail.com

Re: [PHP-DEV] Changes to Git commit workflow

[Bishop Bettini]

On Thu, Apr 1, 2021 at 12:24 PM Sara Golemon  wrote:

> On Thu, Apr 1, 2021 at 11:19 AM Rowan Tommins 
> wrote:
>
> > On 01/04/2021 15:59, Sara Golemon wrote:
> > > On Thu, Apr 1, 2021 at 9:21 AM Bishop Bettini  > > > wrote:
> > >
> > > I also added a FAQ.
> > >
> > >
> > > I disagree with the position this document takes on immortal keys.  We
> > > should encourage best-practices with the knowledge that some people
> > > will weaken their security with an immortal key, not start from a weak
> > > position and suggest that adhering to best practices is "paranoid".
> >
> >
> > I've been looking around, and most of what I can find says that expiring
> > a primary key which you use directly for signing has very little value,
> > because anyone who has the private key and passphrase can change the
> > expiry date at any time.  See for example:
> > https://security.stackexchange.com/q/14718/51961
> >
> > The main use case seems to be when using sub-keys, where the primary key
> > (with no expiry) is kept offline, and new sub-keys are generated from it
> > regularly (e.g. once a year) with an appropriate expiry date.
> >
> > This is based only on a few hours of searching online, however, so I'd
> > be happy to see a better explanation of how to use expiry effectively.
> >
> >
> Yeah, I just got told the same offline.  That's depressing.  Not
> surprising when one thinks about it more, but still depressing.
>

Appreciate the feedback, Sara and Rowan!

I think there was still opportunity to improve that section, so I adjusted
the language to be less accusatory and highlight the essential limitations.

Re: [PHP-DEV] Changes to Git commit workflow

[Sara Golemon]

On Thu, Apr 1, 2021 at 11:19 AM Rowan Tommins 
wrote:

> On 01/04/2021 15:59, Sara Golemon wrote:
> > On Thu, Apr 1, 2021 at 9:21 AM Bishop Bettini  > > wrote:
> >
> > I also added a FAQ.
> >
> >
> > I disagree with the position this document takes on immortal keys.  We
> > should encourage best-practices with the knowledge that some people
> > will weaken their security with an immortal key, not start from a weak
> > position and suggest that adhering to best practices is "paranoid".
>
>
> I've been looking around, and most of what I can find says that expiring
> a primary key which you use directly for signing has very little value,
> because anyone who has the private key and passphrase can change the
> expiry date at any time.  See for example:
> https://security.stackexchange.com/q/14718/51961
>
> The main use case seems to be when using sub-keys, where the primary key
> (with no expiry) is kept offline, and new sub-keys are generated from it
> regularly (e.g. once a year) with an appropriate expiry date.
>
> This is based only on a few hours of searching online, however, so I'd
> be happy to see a better explanation of how to use expiry effectively.
>
>
Yeah, I just got told the same offline.  That's depressing.  Not
surprising when one thinks about it more, but still depressing.

-Sara

Re: [PHP-DEV] Changes to Git commit workflow

[Rowan Tommins]

On 01/04/2021 15:59, Sara Golemon wrote:
On Thu, Apr 1, 2021 at 9:21 AM Bishop Bettini > wrote:


I also added a FAQ.


I disagree with the position this document takes on immortal keys.  We 
should encourage best-practices with the knowledge that some people 
will weaken their security with an immortal key, not start from a weak 
position and suggest that adhering to best practices is "paranoid".



I've been looking around, and most of what I can find says that expiring 
a primary key which you use directly for signing has very little value, 
because anyone who has the private key and passphrase can change the 
expiry date at any time.  See for example: 
https://security.stackexchange.com/q/14718/51961


The main use case seems to be when using sub-keys, where the primary key 
(with no expiry) is kept offline, and new sub-keys are generated from it 
regularly (e.g. once a year) with an appropriate expiry date.


This is based only on a few hours of searching online, however, so I'd 
be happy to see a better explanation of how to use expiry effectively.


Regards,

--
Rowan Tommins
[IMSoP]

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

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

[Andreas Leathley]

On 01.04.21 17:07, Benjamin Eberlei wrote:

I don't know, you are arguing that you forgot a return, but you also did
not forget to add a never return type. You
could easily fix this by inlining the exception instead.

```php
if (!isset($user)) {
throw new NotFoundException();
}
```
Even when you insist on the function, it is a one liner that throws
immediately. Adding the never return type there isn't going to catch a
great many bugs.


Throwing an exception immediately is an alternative, but this only works
if that is the absolute only thing the method does, and even then it
leads to a lot of repetition (if you have many controllers) with very
specific code shared in each controller. Making the identical behavior
between controllers explicit by a shared "notFound" method seems better
coding to me, and it has the advantage of being very readable and
something you can easily recognize between different controllers - you
look it up once and know what it does. If you throw exceptions in each
controller, you might wonder if this is the exact same exception as
another one in another controller. Often you might also want to change
the behavior at some point - for example log the event before throwing
the exception, or handling notFound entirely different. noreturn/never
gives you the flexibility to refactor "throw NotFoundException();" into
a method while keeping the promise that the code flow will not continue.

Abstracting away something like a redirect, an authorization problem or
a 404 also seems an improvement to me (compared to "throw
NotFoundException();") because you write and test that logic once, and
then reuse it in different places. Like with other parts of the type
system in PHP noreturn/never just gives you stronger guarantees and more
information about what a function/method is ought to do and how it behaves.

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

Re: [PHP-DEV] Changes to Git commit workflow

[Bishop Bettini]

On Thu, Apr 1, 2021 at 11:32 AM Christoph M. Becker 
wrote:

> On 01.04.2021 at 17:09, Kalle Sommer Nielsen wrote:
>
> > Den tor. 1. apr. 2021 kl. 07.55 skrev Bishop Bettini :
> >
> >> I've documented why we need signing, and how to set it up:
> >>
> >> https://wiki.php.net/vcs/commit-signing
> >>
> >> Feedback welcomed!
> >
> > Great guide,
>
> Yes, thanks for that, Bishop!
>
> > any chance to add some Windows information here?
>
> For step 1 - 3, that would basically be to download and install
>  and to execute Kleopatra; the GUI should be
> pretty much self explaining.
>
> Step 4 (copying to clipboard) might not be supported, but the default
> export should work fine (could copy to clipboard from the exported file
> then).  Make sure that you don't export the private key here.
>
> Steps 5 - 7 should be identical.
>
> Note that Kleopatra must be running, whenever you want to sign a commit.
>

Thanks Christoph! Excellent information.

I will try this locally and update the guide.

Re: [PHP-DEV] Changes to Git commit workflow

[Christoph M. Becker]

On 01.04.2021 at 17:09, Kalle Sommer Nielsen wrote:

> Den tor. 1. apr. 2021 kl. 07.55 skrev Bishop Bettini :
>
>> I've documented why we need signing, and how to set it up:
>>
>> https://wiki.php.net/vcs/commit-signing
>>
>> Feedback welcomed!
>
> Great guide,

Yes, thanks for that, Bishop!

> any chance to add some Windows information here?

For step 1 - 3, that would basically be to download and install
 and to execute Kleopatra; the GUI should be
pretty much self explaining.

Step 4 (copying to clipboard) might not be supported, but the default
export should work fine (could copy to clipboard from the exported file
then).  Make sure that you don't export the private key here.

Steps 5 - 7 should be identical.

Note that Kleopatra must be running, whenever you want to sign a commit.

--
Christoph M. Becker

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

Re: [PHP-DEV] Changes to Git commit workflow

[Kalle Sommer Nielsen]

Hi Bishop

Den tor. 1. apr. 2021 kl. 07.55 skrev Bishop Bettini :
> I've documented why we need signing, and how to set it up:
>
> https://wiki.php.net/vcs/commit-signing
>
> Feedback welcomed!

Great guide, any chance to add some Windows information here?

-- 
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] [VOTE] noreturn type

[Benjamin Eberlei]

On Thu, Apr 1, 2021 at 3:56 PM Andreas Leathley  wrote:

> On 01.04.21 10:56, Benjamin Eberlei wrote:
> > This RFC is using the declaration of the return type, to specify that it
> > never returns. As such noreturn or never is a keyword a long the lines of
> > public or final, but it is not a return type.
> >
> > I don't think the argument for potential optimizations in Opcache to
> > eliminate dead code or allow IDEs to hint at dead code are valuable
> enough
> > to justify this change.
>
> I already use @return no-return (supported by Psalm/PHPStan) in my code
> now, to clarify the code flow, and for me it fits perfectly for return
> types, as not returning is also a result of the function/method. Having
> a return type of "int" or "string" (or even "void") seems misleading
> when the method will never return anyway.
>
> noreturn/never might not be useful in all code, but for some parts like
> in a controller of a web application it makes handling redirects,
> authorization or 404 errors much easier, clearer and less error-prone,
> for example:
>
> ```php
> if (!isset($user)) {
>$this->notFound(); // this is a noreturn/never method
> }
>
> if (!$this->isGranted('adminPrivileges')) {
>$this->notAuthorized(); // this is a noreturn/never method
> }
> ```
>
> Adding noreturn/never on a language level would make sure calling
> "$this->notAuthorized();" never continues code flow. This is often also
> a security issue, as seen by an alternative way of handling the above
> use cases:
>
> ```php
> if (!isset($user)) {
>$this->notFound();
>return;
> }
>
> if (!$this->isGranted('adminPrivileges')) {
>$this->notAuthorized();
>return;
> }
> ```
>
> If you forget a return, suddenly you have issues. So even though
> noreturn/never is a niche language feature not everyone will use, it
> does address a very real use case.


I don't know, you are arguing that you forgot a return, but you also did
not forget to add a never return type. You
could easily fix this by inlining the exception instead.

```php
if (!isset($user)) {
   throw new NotFoundException();
}
```
Even when you insist on the function, it is a one liner that throws
immediately. Adding the never return type there isn't going to catch a
great many bugs.



> Using attributes has the disadvantage
> of not making the intent clear:
>

> ```php
> #[\NoReturn]
> function notAuthorized(): string
> {
>// Some code
> }
> ```
>
> Now you have a return type of string, but also the information that the
> function will never return anyway. That is confusing, but will be
> inevitable in some cases when implementing interfaces or an abstract
> class. In my opinion, the string return type is wrong in this case and
> can only mislead a developer.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Changes to Git commit workflow

[Sara Golemon]

On Thu, Apr 1, 2021 at 9:21 AM Bishop Bettini  wrote:

> I also added a FAQ.
>
>
I disagree with the position this document takes on immortal keys.  We
should encourage best-practices with the knowledge that some people will
weaken their security with an immortal key, not start from a weak position
and suggest that adhering to best practices is "paranoid".

-Sara

Re: [PHP-DEV] [VOTE] Object scoped RNG implementation

[Go Kudo]

Hi Xavier

> If I understand correctly, this would
>  - provide us with performant object-encapsulated (isolated from global
state) equivalents of the existing `mt_srand()`/`mt_rand()` and
`random_int()` functions as well as a new "XorShift128+"; along with some
global functions for usability, notably `rng_bytes()` and `rng_int()`
respectively similar to `random_bytes()` and `random_int()` but with an
additional (first) RNG argument
>  - enable us to use them (the objects), as well as other (extension or
userland) implementations of the `RNG\RNGInterface`, for the existing
`array_rand()`, `shuffle()` and `str_shuffle()` functions (instead of the
default internal MT implementation)

Yes, that's right.

> I can't vote (yes), but I just suggest you complete the stubs in the RFC
with what can been seen at <
https://github.com/php/php-src/pull/6568/files?file-filters%5B%5D=.php#diff-d469bf38690924187e7b9db4a8ab199a99394b404bb12325a789141c56edb12f>
and below, showing that the class `OS` has the minimal interface while
classes `MT19937` and `XorShift128Plus` have a public
`__construct(int $seed)` and implement the magic
`__serialize()`/`__unserialize()`.

I've added it to the RFC.
Thank you!

Re: [PHP-DEV] Changes to Git commit workflow

[Bishop Bettini]

On Thu, Apr 1, 2021 at 9:22 AM Rowan Tommins 
wrote:

> On 01/04/2021 05:54, Bishop Bettini wrote:
> > I've documented why we need signing, and how to set it up:
> >
> > https://wiki.php.net/vcs/commit-signing
> >
> > Feedback welcomed!
>
>
> This looks great, and very easy to follow.
>
> One edit I would strongly suggest though:
>
> Remove the "Passphrase:" line from the --generate-key command, so that
> gpg will prompt interactively for the passphrase using the same entry as
> it will use later when signing. You should never include a password or
> passphrase in a command if you can avoid it, as it will be visible on
> your screen, and stored in plain text in your shell history.
>
>
> Some additional tips that might be worth adding:
>
> As an advanced setup suggestion, "gpg --full-generate-key" launches a
> wizard with a couple of extra prompts.
>
> If you're on Ubuntu and don't have a new enough git (e.g. 18.04LTS ships
> with 2.17.1), there is an official PPA to upgrade it; just run: "sudo
> add-apt-repository ppa:git-core/ppa && sudo apt update && sudo apt
> install git"
>
> Before pushing to github, you can verify the signature on a commit
> locally with "git show --show-signature HEAD", or similarly for a tag by
> passing the tag name.
>

Excellent suggestions. I've updated the guide with these.

I also added a FAQ.

https://wiki.php.net/vcs/commit-signing

Thank you!

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

[Andreas Leathley]

On 01.04.21 10:56, Benjamin Eberlei wrote:

This RFC is using the declaration of the return type, to specify that it
never returns. As such noreturn or never is a keyword a long the lines of
public or final, but it is not a return type.

I don't think the argument for potential optimizations in Opcache to
eliminate dead code or allow IDEs to hint at dead code are valuable enough
to justify this change.


I already use @return no-return (supported by Psalm/PHPStan) in my code
now, to clarify the code flow, and for me it fits perfectly for return
types, as not returning is also a result of the function/method. Having
a return type of "int" or "string" (or even "void") seems misleading
when the method will never return anyway.

noreturn/never might not be useful in all code, but for some parts like
in a controller of a web application it makes handling redirects,
authorization or 404 errors much easier, clearer and less error-prone,
for example:

```php
if (!isset($user)) {
  $this->notFound(); // this is a noreturn/never method
}

if (!$this->isGranted('adminPrivileges')) {
  $this->notAuthorized(); // this is a noreturn/never method
}
```

Adding noreturn/never on a language level would make sure calling
"$this->notAuthorized();" never continues code flow. This is often also
a security issue, as seen by an alternative way of handling the above
use cases:

```php
if (!isset($user)) {
  $this->notFound();
  return;
}

if (!$this->isGranted('adminPrivileges')) {
  $this->notAuthorized();
  return;
}
```

If you forget a return, suddenly you have issues. So even though
noreturn/never is a niche language feature not everyone will use, it
does address a very real use case. Using attributes has the disadvantage
of not making the intent clear:

```php
#[\NoReturn]
function notAuthorized(): string
{
  // Some code
}
```

Now you have a return type of string, but also the information that the
function will never return anyway. That is confusing, but will be
inevitable in some cases when implementing interfaces or an abstract
class. In my opinion, the string return type is wrong in this case and
can only mislead a developer.

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

Re: [PHP-DEV] Changes to Git commit workflow

[Rowan Tommins]

On 01/04/2021 05:54, Bishop Bettini wrote:

I've documented why we need signing, and how to set it up:

https://wiki.php.net/vcs/commit-signing

Feedback welcomed!



This looks great, and very easy to follow.

One edit I would strongly suggest though:

Remove the "Passphrase:" line from the --generate-key command, so that 
gpg will prompt interactively for the passphrase using the same entry as 
it will use later when signing. You should never include a password or 
passphrase in a command if you can avoid it, as it will be visible on 
your screen, and stored in plain text in your shell history.



Some additional tips that might be worth adding:

As an advanced setup suggestion, "gpg --full-generate-key" launches a 
wizard with a couple of extra prompts.


If you're on Ubuntu and don't have a new enough git (e.g. 18.04LTS ships 
with 2.17.1), there is an official PPA to upgrade it; just run: "sudo 
add-apt-repository ppa:git-core/ppa && sudo apt update && sudo apt 
install git"


Before pushing to github, you can verify the signature on a commit 
locally with "git show --show-signature HEAD", or similarly for a tag by 
passing the tag name.



Regards,

--
Rowan Tommins
[IMSoP]

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

Re: [PHP-DEV] Re: Changes to Git commit workflow

[Sara Golemon]

On Thu, Apr 1, 2021 at 2:59 AM Sebastian Bergmann  wrote:

> Am 01.04.2021 um 09:58 schrieb Jan Ehrhardt:
> > Will PHP 8.0.4 and 7.4.17 be postponed because of this? They haven't been
> > released yet. The usual day for tagging always was Tuesday or Wednesday.
>
> Yes, see https://twitter.com/official_php/status/1377339882645905408
>
>
Or even the front page of php.net, this was announced on Tuesday when
tagging normally would have taken place.

-Sara

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

[Matthew Brown]

On Tue, 30 Mar 2021 at 13:51, Ilija Tovilo  wrote:

> Hi Matthew
>
> > I like the proposal. I also support the covariance.
> >
> > One question though.
> > The RFC mentions possible future use of "nothing" as a bottom type for
> > parameters in generics. This makes a lot of sense to me. Even without
> > generics, it could be used for parameters in abstract methods.
> >
> > So why not already introduce "nothing" as the universal bottom type, and
> > use it instead of "noreturn"?
> > Can "noreturn" do anything that "nothing" can't?
>
> I'm also a little confused by this statement. The exact wording from the
> RFC is:
>
> > Arguments for never: ... It's a full-fledged type, rather than a keyword
> used in a specific situation. A far-in-the-future generics proposal could
> use never as a placeholder inside contravariant generic types.
>
> From what I understand, in Hack noreturn and never are both
> full-fledged types. Nothing is a bottom type while noreturn is not.
> Since in your proposal noreturn would also be a bottom type there's no
> reason why it couldn't be used in covariant or contravariant generic
> parameters.
>
> Please correct me if I'm missing something.
>
> Ilija
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
In Hack it's a bit confusing. I think the Hack team ultimately decided that
"nothing" was a better name for the bottom type than "noreturn", and
confusingly introduced one while the other was still active.

They have a long-term plan to deprecate "noreturn" in favour of "nothing"
and stop supporting the former name, though it's unclear when that might
happen.

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

[Matthew Brown]

On Thu, 1 Apr 2021 at 04:56, Benjamin Eberlei  wrote:

> This RFC is using the declaration of the return type, to specify that it
> never returns. As such noreturn or never is a keyword a long the lines of
> public or final, but it is not a return type.
>
> I don't think the argument for potential optimizations in Opcache to
> eliminate dead code or allow IDEs to hint at dead code are valuable enough
> to justify this change.
>

By this argument "void" should also be an attribute – there's no reason to
hint a value that's not being returned.

You'd write functions like

[\Void]
function foo() { ... }

But we don't do that, because the wider programming language community has
agreed that "void" is a type, and at compile-time PHP's engine can ensure
that "void" functions do not return a value.

"Noreturn"/"never" is also recognised as a type by the wider programming
language community. It can be checked at both compile-time and run-time by
the engine, as detailed in the RFC. Indeed, _no other return type makes
sense in the context_.

The type definitely felt awkward when I first started using it in
docblocks, but after a while it started to make intuitive sense.

Best wishes,

Matt/Ondrej

Re: [PHP-DEV] Why is assert limited to a debugging feature only?

[Rowan Tommins]

Hi,

On 1 April 2021 09:24:54 BST, Arnold Daniels  
wrote:
>The documentation of `assert`
>([https://php.net/assert)](https://www.php.net/manual/en/function.assert.php))
>states that's debugging only. This is further enforced by php.ini flags
>to disable assertions in production.

This is, in a sense, looking at things the wrong way around: the main feature 
of the built-in assert() statement is that it can be disabled in production, 
and the assertion code will not run at all. That feature is useful if you want 
to write assertions that run in development but have zero performance cost in 
production.

If you leave them switched on permanently, the advantage of using the built-in 
assert() over writing your own becomes very small - the definition would be two 
simple lines of code. There's nothing to stop you doing that, though; the 
documentation is just giving advice.

The two libraries you linked to concentrate on a very different feature: 
concisely writing certain common conditions, such as type and range checks. It 
might seem reasonable to include common features like this in the language, but 
the fact that you linked two different libraries demonstrates why that might 
not be a good idea: the API and feature set are hard to get right. Once a 
feature is added to the language it is very difficult to change.

Regards,

-- 
Rowan Tommins
[IMSoP]

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

[PHP-DEV] [VOTE] Deprecate implicit non-integer-compatible float to int conversions

[G. P. B.]

Hello internals,

It's been a couple of weeks and no further comments have been made as such
voting is now open:

https://wiki.php.net/rfc/implicit-float-int-deprecate

It will run for two weeks until the 14th of April 2021.

Best regards,

George P. Banyard

Re: [PHP-DEV] [VOTE] Object scoped RNG implementation

[Guilliam Xavier]

On Thu, Apr 1, 2021 at 6:39 AM Go Kudo  wrote:

> Hello everyone.
>
> Object scoped RNG RFC vote is now open.
> https://wiki.php.net/rfc/object_scope_prng
>
> The deadline for voting is April 15.
>
> Previous discussions can be viewed below.
>
> https://externals.io/message/112765
> https://externals.io/message/112819
> https://externals.io/message/113720
>
> Regards,
> Go Kudo
>

Hello,

If I understand correctly, this would
  - provide us with performant object-encapsulated (isolated from global
state) equivalents of the existing `mt_srand()`/`mt_rand()` and
`random_int()` functions as well as a new "XorShift128+"; along with some
global functions for usability, notably `rng_bytes()` and `rng_int()`
respectively similar to `random_bytes()` and `random_int()` but with an
additional (first) RNG argument
  - enable us to use them (the objects), as well as other (extension or
userland) implementations of the `RNG\RNGInterface`, for the existing
`array_rand()`, `shuffle()` and `str_shuffle()` functions (instead of the
default internal MT implementation)
?

I can't vote (yes), but I just suggest you complete the stubs in the RFC
with what can been seen at <
https://github.com/php/php-src/pull/6568/files?file-filters%5B%5D=.php#diff-d469bf38690924187e7b9db4a8ab199a99394b404bb12325a789141c56edb12f>
and below, showing that the class `OS` has the minimal interface while
classes `MT19937` and `XorShift128Plus` have a public `__construct(int $seed
)` and implement the magic `__serialize()`/`__unserialize()`.

Best regards,

-- 
Guilliam Xavier

Re: [PHP-DEV] Changes to Git commit workflow

[Markus Fischer]

Hi Bishop,

On 01.04.21 06:54, Bishop Bettini wrote:

I've documented why we need signing, and how to set it up:

https://wiki.php.net/vcs/commit-signing

Feedback welcomed!


I'm not even the target audience in terms of php-src access, but rarely 
have I seen such a good tutorial approach on this (though have not 
tested it).


Just wanted to mention this, really great. It mentions it's based on 
internal LifeOmic docs, so kudos to them too I guess :)


- Markus

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

Re: [PHP-DEV] Why is assert limited to a debugging feature only?

[Pierre]

Le 01/04/2021 à 10:50, Olle Härstedt a écrit :

Dunno about the motivation of the implementors, but usually assertions
are used for internal invariants and mental checks while exceptions
should be used for interaction with the outside world (database
errors, user input errors etc). If you follow this, an assert error
will never be useful for a user, it will always be an "internal
error", and that's why it can (should?) be disabled in production.

Olle


Hello,

I don't know about the original motivations either, but at work we 
mostly use to force IDEs to understand types where PHP can't enforce 
them, due to its highly dynamic nature and lacks of generics. Most of 
our assert usage as like this: \asset($foo instanceof Bar);


We never enable those on production, we have assert() calls pretty much 
everywhere and they don't serve any other purpose than being explicit 
for the code readers and IDE and we use them for debugging purpose: it 
raises exceptions for developer preventing them to proceed further until 
they fixe the bugs, but they don't break the production.


Regards,

--

Pierre

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

Re: [PHP-DEV] Why is assert limited to a debugging feature only?

[Guilliam Xavier]

On Thu, Apr 1, 2021 at 10:50 AM Olle Härstedt 
wrote:

> 2021-04-01 10:24 GMT+02:00, Arnold Daniels :
> > Hi,
> >
> > The documentation of `assert`
> > ([
> https://php.net/assert)](https://www.php.net/manual/en/function.assert.php
> ))
> > states that's debugging only. This is further enforced by php.ini flags
> to
> > disable assertions in production.
> >
> > Why are the use cases of this feature being limited to debugging? We can
> see
> > from the popularity of user-space assertion libraries, like
> > [webmozart/asset](https://packagist.org/packages/webmozart/assert) and
> > [beberlei/assert](https://packagist.org/packages/beberlei/assert), that
> > there is a need for runtime assertions.
> >
> > [Arnold Daniels - Chat @
> > Spike](https://spikenow.com/r/a/?ref=spike-organic-signature&_ts=yux2k)
>  [yux2k]
>
> Dunno about the motivation of the implementors, but usually assertions
> are used for internal invariants and mental checks while exceptions
> should be used for interaction with the outside world (database
> errors, user input errors etc). If you follow this, an assert error
> will never be useful for a user, it will always be an "internal
> error", and that's why it can (should?) be disabled in production.
>
> Olle
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Hi,

I agree with Olle's explanation (and am indeed using `assert()` that way).
Also note that both linked libs throw `InvalidArgumentException`
(subclasses of), so not the same kind of "assertions" (despite the name).

Regards,

-- 
Guilliam Xavier

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

[Sebastian Bergmann]

Am 01.04.2021 um 10:56 schrieb Benjamin Eberlei:

I voted no, because i think this should at the maximum be an attribute.

This RFC is using the declaration of the return type, to specify that it
never returns. As such noreturn or never is a keyword a long the lines of
public or final, but it is not a return type.

I don't think the argument for potential optimizations in Opcache to
eliminate dead code or allow IDEs to hint at dead code are valuable enough
to justify this change.


Following Benjamin's argument, I have changed my vote to no.

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

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

[Benjamin Eberlei]

On Tue, Mar 30, 2021 at 5:07 PM Matthew Brown 
wrote:

> Hey everyone!
>
> The vote for adding noreturn is now open:
>
> https://wiki.php.net/rfc/noreturn_type
>
> Voting will run through April 13th
>
> Best wishes,
>
> Matt and Ondrej
>

I voted no, because i think this should at the maximum be an attribute.

This RFC is using the declaration of the return type, to specify that it
never returns. As such noreturn or never is a keyword a long the lines of
public or final, but it is not a return type.

I don't think the argument for potential optimizations in Opcache to
eliminate dead code or allow IDEs to hint at dead code are valuable enough
to justify this change.

Re: [PHP-DEV] Why is assert limited to a debugging feature only?

[Olle Härstedt]

2021-04-01 10:24 GMT+02:00, Arnold Daniels :
> Hi,
>
> The documentation of `assert`
> ([https://php.net/assert)](https://www.php.net/manual/en/function.assert.php))
> states that's debugging only. This is further enforced by php.ini flags to
> disable assertions in production.
>
> Why are the use cases of this feature being limited to debugging? We can see
> from the popularity of user-space assertion libraries, like
> [webmozart/asset](https://packagist.org/packages/webmozart/assert) and
> [beberlei/assert](https://packagist.org/packages/beberlei/assert), that
> there is a need for runtime assertions.
>
> [Arnold Daniels - Chat @
> Spike](https://spikenow.com/r/a/?ref=spike-organic-signature&_ts=yux2k)   
> [yux2k]

Dunno about the motivation of the implementors, but usually assertions
are used for internal invariants and mental checks while exceptions
should be used for interaction with the outside world (database
errors, user input errors etc). If you follow this, an assert error
will never be useful for a user, it will always be an "internal
error", and that's why it can (should?) be disabled in production.

Olle

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

[PHP-DEV] Why is assert limited to a debugging feature only?

[Arnold Daniels]

Hi,

The documentation of `assert` 
([https://php.net/assert)](https://www.php.net/manual/en/function.assert.php)) 
states that's debugging only. This is further enforced by php.ini flags to 
disable assertions in production.

Why are the use cases of this feature being limited to debugging? We can see 
from the popularity of user-space assertion libraries, like 
[webmozart/asset](https://packagist.org/packages/webmozart/assert) and 
[beberlei/assert](https://packagist.org/packages/beberlei/assert), that there 
is a need for runtime assertions.

[Arnold Daniels - Chat @ 
Spike](https://spikenow.com/r/a/?ref=spike-organic-signature&_ts=yux2k)
[yux2k]

Re: [PHP-DEV] Re: Changes to Git commit workflow

[Sebastian Bergmann]

Am 01.04.2021 um 09:58 schrieb Jan Ehrhardt:

Will PHP 8.0.4 and 7.4.17 be postponed because of this? They haven't been
released yet. The usual day for tagging always was Tuesday or Wednesday.


Yes, see https://twitter.com/official_php/status/1377339882645905408

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

[PHP-DEV] Re: Changes to Git commit workflow

[Jan Ehrhardt]

Nikita Popov in php.internals (Mon, 29 Mar 2021 00:52:24 +0200):
>We're reviewing the repositories for any corruption beyond the two
>referenced commits.

Will PHP 8.0.4 and 7.4.17 be postponed because of this? They haven't been
released yet. The usual day for tagging always was Tuesday or Wednesday.
-- 
Jan

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