Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics

[Mark Randall]

On 17/07/2020 04:49, Levi Morrison via internals wrote:

I don't care to debate it. I will just vote no.


Fair enough, however the point of the internals mailing list and 
discussion period is to debate the RFCs :-)



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

Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics

[Levi Morrison via internals]

On Thu, Jul 16, 2020 at 9:29 PM Mark Randall  wrote:
>
> On 17/07/2020 02:58, Levi Morrison via internals wrote:
> >2. I don't think this is solving any problems, really:
> >  - Code can move from PHP land to an extension and back again.
> > Should the namespace change just because it moved one way or the
> > other? I vote no.
>
> This is not what the RFC proposes. The point of \Ext is that there would
> be no need to rename them when moving in or out of core.

This is not quite the same. I said it moves from _userland_ aka PHP
code, to an _extension_ aka C code. I oppose `Ext` in both case.

> > I'm strongly in the "make namespace short and flat" camp. Deeply
> > nested namespaces make more sense when you need to distinguish between
> > projects within a company, for a contrived example
> > `Amazon\WebServices\SDK`. I can see there being multiple projects with
> > Amazon, and I can see there being multiple WebServices projects.
> > Removing a namespace segment doesn't make a lot of sense either,
> > except for perhaps collapsing the first two to `AWS` but this is just
> > another point to my short and flat camp. This deeply nested company
> > organization is not the territory we are in as a project, so we should
> > keep it simple and keep our namespace short and simple.
>
> How flat would you want it to be? This RFC proposes 1 level before the
> name of the feature, either PHP or Ext depending on its location. The
> purpose of that one level is to avoid extensions trampling into multiple
> userspace naming areas.

There is no need to separate between _extensions_ and _userland_ code.
I believe this very premise is flawed.

I don't care to debate it. I will just vote no.

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

Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics

[Mark Randall]

On 17/07/2020 02:58, Levi Morrison via internals wrote:

   2. I don't think this is solving any problems, really:
 - Code can move from PHP land to an extension and back again.
Should the namespace change just because it moved one way or the
other? I vote no.


This is not what the RFC proposes. The point of \Ext is that there would 
be no need to rename them when moving in or out of core.






I'm strongly in the "make namespace short and flat" camp. Deeply
nested namespaces make more sense when you need to distinguish between
projects within a company, for a contrived example
`Amazon\WebServices\SDK`. I can see there being multiple projects with
Amazon, and I can see there being multiple WebServices projects.
Removing a namespace segment doesn't make a lot of sense either,
except for perhaps collapsing the first two to `AWS` but this is just
another point to my short and flat camp. This deeply nested company
organization is not the territory we are in as a project, so we should
keep it simple and keep our namespace short and simple.


How flat would you want it to be? This RFC proposes 1 level before the 
name of the feature, either PHP or Ext depending on its location. The 
purpose of that one level is to avoid extensions trampling into multiple 
userspace naming areas.


Mark Randall

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

Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics

[Levi Morrison via internals]

On Thu, Jul 16, 2020 at 3:42 PM Larry Garfield  wrote:
>
> After some discussion, the namespacing proposal has been again updated.  Two 
> major changes:
>
> 1) Only engine code goes in \PHP.  There's a separate \Ext namespace for 
> extensions, whether bundled or PECL.
>
> 2) It establishes that an index will be maintained on the Wiki listing what 
> namespaces are already claimed.
>
> https://wiki.php.net/rfc/php_namespace_policy
>
> This is probably (I hope) the final edit of consequence before voting.  Speak 
> now or forever hold your peace. :-)

Chiming in to formally oppose `\Ext`. I don't think it holds much
value for a few reasons:

  1. If all extensions are in the same namespace then they have to
work out conflicts between themselves anyway. This would not have
helped mongo and mongodb, for instance, nor memcache and memcached.
  2. I don't think this is solving any problems, really:
- Code can move from PHP land to an extension and back again.
Should the namespace change just because it moved one way or the
other? I vote no.
- It's more typing for... what gain, exactly?

I'm strongly in the "make namespace short and flat" camp. Deeply
nested namespaces make more sense when you need to distinguish between
projects within a company, for a contrived example
`Amazon\WebServices\SDK`. I can see there being multiple projects with
Amazon, and I can see there being multiple WebServices projects.
Removing a namespace segment doesn't make a lot of sense either,
except for perhaps collapsing the first two to `AWS` but this is just
another point to my short and flat camp. This deeply nested company
organization is not the territory we are in as a project, so we should
keep it simple and keep our namespace short and simple.

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

Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics

[Larry Garfield]

After some discussion, the namespacing proposal has been again updated.  Two 
major changes:

1) Only engine code goes in \PHP.  There's a separate \Ext namespace for 
extensions, whether bundled or PECL.

2) It establishes that an index will be maintained on the Wiki listing what 
namespaces are already claimed.

https://wiki.php.net/rfc/php_namespace_policy

This is probably (I hope) the final edit of consequence before voting.  Speak 
now or forever hold your peace. :-)

--Larry Garfield

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

[PHP-DEV] PR: Bump libxml version, deprecate libxml_disable_entity_loader()

[Dik Takken]

Hi internals,

I prepared a PR which aims to properly fix a long standing problem
related to secure XML processing in PHP.

In short, it bumps the minimum required version of libxml and it
deprecates the libxml_disable_entity_loader() function.

You can find the details in the PR:

https://github.com/php/php-src/pull/5867

Please have a look.

Thanks,

Dik Takken

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

Re: [PHP-DEV] Re: [RFC] Treat namespaced names as single token, relax reserved keyword restrictions

[Nikita Popov]

On Thu, Jul 16, 2020 at 3:00 PM Theodore Brown 
wrote:

> On Thu, July 16 2020 at 3:04 AM Nikita Popov  wrote:
>
> > While I don't think anyone had plans to mix whitespace, this is
> > indicative of a larger issue. While I'm one of the people who voted
> > for @@ as my first choice before, I wouldn't do so now (even with
> > this RFC accepted). This issue made me realize that there is more at
> > stake here than just "which syntax is prettier?" and choices that
> > have a "closing tag" are technically more favorable, especially if
> > we consider future extensions of the attribute system that may
> > introduce additional ambiguities (e.g., Rust allows placing
> > attributes pretty much everywhere in code -- how sure are we that
> > there will be no unanticipated ambiguities?)
>
> Hi Nikita,
>
> Can you think of an example that would cause an ambiguity even when
> namespaced names are treated as tokens? As I understand it, there
> can't be an ambiguity, since there would always be an attribute token
> followed by a class name token. It should be possible to put this
> anywhere it makes sense without ambiguities.
>

Yes, there should not be any ambiguities at present. This is more of a
vague unease when it comes to future language extensions. To give an
example: Let's say that in the future, we allow annotations on statements,
and introduce generics using the ClassName{T} syntax (it's unlikely we'd
actually do that, even though this is the "least ambiguous" generics
syntax). Now, if attributes are just classes, it would stand to reason that
you can use something like @@OfType{int} as an attribute. If we combine
these two language changes, we get

@@FooBar
{
SomethingComplexHere
}

where SomethignComplexHere could be interpreted both as a type or an
expression. This does not cause a "true" ambiguity, but it does add an
infinite lookahead parser requirement, because we will only know how to
interpret this at the }. It could be an attribute with a generic parameter,
or it could be a non-generic attribute on a code block.

Of course, it is more likely than not, that we will not encounter any
issues of that nature.

Nikita

Re: [PHP-DEV] [RFC][Discussion] Objects can be declared falsifiable

[Josh Bruce]

> On Jul 16, 2020, at 10:28 AM, Josh Bruce  wrote:
> 
> https://wiki.php.net/rfc/objects-can-be-falsifiable 
> 
> 
> Updates:
> 
> - Open issues (outstanding questions/concerns) updated
> - Future scope
> - References now have links to original copies on GitHub (still updating 
> 0002) - will be removed if accepted and implemented.
> - No violent opposition, but concerns - will be looking at how to implement 
> (or set up implementing).
> 
> All:
> 
> Trying to let conversation flow w/o me; sticking to once a day batch updates. 
> Let me know if you’d prefer something else - still learning the Roman-way. :)
> 
> To Larry’s user example. 
> 
> With Falsifiable the User instance becomes more self-aware. __toBool(), which 
> might be more for the object itself, other objects, or PHP itself through a 
> universal, reserved API entry point (like other magic methods).
> 
> Trying to make PHP fail gracefully more by adding to the ability of not 
> returning null (or interacting with null - nullsafe, optionals, and so on).
> 
> (Maybe that should be a table as well??)
> 
> print null; // always succeeds despite being nothing - not a fatal error
> 
> (bool) null; // always succeeds - always false
> 
> (integer|float) null; // always succeeds - always 0
> 
> (array) null; // always succeeds - always []
> 
> (string) null; // always succeeds - always “"
> 
> null->someMethod(); // always fails - crashes app
> 
> I was in the conversations leading up to null being able to handle this much 
> interaction, part makes me go back to something talked about re new 
> developers (paraphrased): It's frustrating to learn software development when 
> it takes a lot to set up and with every turn you take your app crashes - 
> people give up; so, PHP prefers failing gracefully over hard crashes. 
> 
> The only interaction on null that seems to fail outright (from personal 
> experience) is trying to call a method because it’s not an object. (It 
> doesn’t even fail the dread array-to-string conversion. lol)
> 
>> I really appreciate any effort that can make PHP a more powerful language. 
>> However, for this item, I believe it will generate much greater cognitive 
>> complexity for new users (and I hate to assume that this is a problem, but 
>> we have to remember our roots).
> 
> David: Completely agree on respecting new users and devs (see opening bit).
> 
> I’m thinking right now, for me, it’s more about always being able to message 
> the type you expect, even if false (in the abstract), while also letting PHP 
> to interact automatically with it in the ways we have also become accustomed. 
> 
>> (bool) cast working together with __toBool() is a good one, but I think that 
>> it is being discussed in another topic.
> 
> Was it an RFC or email?? 
> 
> If email and within the last week or so, it might be this same conversation. 
> 
> Took a moment to evolve to this kinda hybrid approach. (In short, back to the 
> original implementation, with a pretty different rationale.)
> 
>> The other implication is that this is now possibly *not* a bug:
>> 
>> if (!$foo) {
>> $foo->bar();
>> }
> 
> Matthew: I can see that feeling like a bug, for me it would be a feature 
> (can’t believe I just said that). 
> 
> Objects that return an abstracted (high-level) false, can tell me why 
> (without blowing things up via fatal errors or added syntax and time of 
> try-catch-throw or various permutations of optionals, which is possibly 
> frustrating for new devs - possibly specific to the self-taught, it was for 
> me back in the day - still don’t have the muscle memory for try-catch-throw 
> and implementing errors).
> 
> I can’t ask null any questions - it exists only in the mind (so to speak), 
> but I can send messages to an instance that is abstractly false. (And remove 
> all the null-checks and optionals from (at least) my code that uses it or 
> wraps some package that doesn’t.
> 
> My contract with a function call becomes: You will always get something of 
> this type - period. Whether it’s the one you specifically wanted, that would 
> be debatable, but it will be that type.
> 
>> "Further, the union type bool|Falsifiable will be dynamically added at run 
>> time to any object implementing the reserved __toBool() method, which would 
>> allow stdClass() objects to be defined as Falsifiable also. "
>> 
>> What's that about?
> 
> Larry: Totally lifted from the Stringable RFC - lol: 
> https://wiki.php.net/rfc/stringable  - 
> string|Stringable
> 
> And I don’t know of a way to add an interface to `new stdClass()` - but 
> thought this might be a valid use case:
> 
> $object = new \stdClass();
> $object->__toBool = function() { 
>  return false|true; 
> };
> 
> if (! $object) {
>  // made it
> }
> 
>> "(Including __construct() replacing old style constructors in PHP 7.)" - 
>> __construct replaced old-style constructors in PHP 5. :-)
> 
> Here’s whe

Re: [PHP-DEV] [RFC] Treat namespaced names as single token, relax reserved keyword restrictions

[Josh Bruce]

> On Jul 15, 2020, at 3:26 AM, Nikita Popov  wrote:
> 
> On Tue, Jul 14, 2020 at 5:37 PM Josh Bruce  > wrote:
> New to the discussion and being this deep; so, apologies for any bumps. 
> Mainly questions.
> 
> Does this only affect the string after the “namespace” keyword (make implicit 
> explicit)?
> 
> This affects any place accepting namespaced names. The only part that is 
> specific to the "namespace" keyword is that you can write "namespace 
> reserved_keyword;", which would not automatically be the case based on the 
> rest of the proposal. 
> 
> So, things like “use” with a stack of classes within a base namespace would 
> still be possible?
> 
> You mean the group use syntax "use Foo\Bar\{A, B};"? That's still possible. 
> In this case we'd interpret Foo\Bar" as a namespaced name and "\" as an 
> isolated namespace separator. This is the only case where "\" is still used 
> as an independent symbol.
>  
> On reserved words, if I had class “String” would that still throw a reserved 
> word violation?
> 
> Yes, nothing about handling of reserved class names is changing under the 
> current proposal.
> 
> Nikita

Got it. Thanks Nikita!

Much appreciated and could have a fair amount of benefit on both sides of the 
equation (dev and PHP).

Cheers,
Josh

Re: [PHP-DEV] [RFC][Discussion] Objects can be declared falsifiable

[Josh Bruce]

https://wiki.php.net/rfc/objects-can-be-falsifiable 


Updates:

- Open issues (outstanding questions/concerns) updated
- Future scope
- References now have links to original copies on GitHub (still updating 0002) 
- will be removed if accepted and implemented.
- No violent opposition, but concerns - will be looking at how to implement (or 
set up implementing).

All:

Trying to let conversation flow w/o me; sticking to once a day batch updates. 
Let me know if you’d prefer something else - still learning the Roman-way. :)

To Larry’s user example. 

With Falsifiable the User instance becomes more self-aware. __toBool(), which 
might be more for the object itself, other objects, or PHP itself through a 
universal, reserved API entry point (like other magic methods).

Trying to make PHP fail gracefully more by adding to the ability of not 
returning null (or interacting with null - nullsafe, optionals, and so on).

(Maybe that should be a table as well??)

print null; // always succeeds despite being nothing - not a fatal error

(bool) null; // always succeeds - always false

(integer|float) null; // always succeeds - always 0

(array) null; // always succeeds - always []

(string) null; // always succeeds - always “"

null->someMethod(); // always fails - crashes app

I was in the conversations leading up to null being able to handle this much 
interaction, part makes me go back to something talked about re new developers 
(paraphrased): It's frustrating to learn software development when it takes a 
lot to set up and with every turn you take your app crashes - people give up; 
so, PHP prefers failing gracefully over hard crashes. 

The only interaction on null that seems to fail outright (from personal 
experience) is trying to call a method because it’s not an object. (It doesn’t 
even fail the dread array-to-string conversion. lol)

> I really appreciate any effort that can make PHP a more powerful language. 
> However, for this item, I believe it will generate much greater cognitive 
> complexity for new users (and I hate to assume that this is a problem, but we 
> have to remember our roots).

David: Completely agree on respecting new users and devs (see opening bit).

I’m thinking right now, for me, it’s more about always being able to message 
the type you expect, even if false (in the abstract), while also letting PHP to 
interact automatically with it in the ways we have also become accustomed. 

> (bool) cast working together with __toBool() is a good one, but I think that 
> it is being discussed in another topic.

Was it an RFC or email?? 

If email and within the last week or so, it might be this same conversation. 

Took a moment to evolve to this kinda hybrid approach. (In short, back to the 
original implementation, with a pretty different rationale.)

> The other implication is that this is now possibly *not* a bug:
> 
> if (!$foo) {
>  $foo->bar();
> }

Matthew: I can see that feeling like a bug, for me it would be a feature (can’t 
believe I just said that). 

Objects that return an abstracted (high-level) false, can tell me why (without 
blowing things up via fatal errors or added syntax and time of try-catch-throw 
or various permutations of optionals, which is possibly frustrating for new 
devs - possibly specific to the self-taught, it was for me back in the day - 
still don’t have the muscle memory for try-catch-throw and implementing errors).

I can’t ask null any questions - it exists only in the mind (so to speak), but 
I can send messages to an instance that is abstractly false. (And remove all 
the null-checks and optionals from (at least) my code that uses it or wraps 
some package that doesn’t.

My contract with a function call becomes: You will always get something of this 
type - period. Whether it’s the one you specifically wanted, that would be 
debatable, but it will be that type.

> "Further, the union type bool|Falsifiable will be dynamically added at run 
> time to any object implementing the reserved __toBool() method, which would 
> allow stdClass() objects to be defined as Falsifiable also. "
> 
> What's that about?

Larry: Totally lifted from the Stringable RFC - lol: 
https://wiki.php.net/rfc/stringable  - 
string|Stringable

And I don’t know of a way to add an interface to `new stdClass()` - but thought 
this might be a valid use case:

$object = new \stdClass();
$object->__toBool = function() { 
  return false|true; 
};

if (! $object) {
  // made it
}

> "(Including __construct() replacing old style constructors in PHP 7.)" - 
> __construct replaced old-style constructors in PHP 5. :-)

Here’s where I got that from: 
https://www.php.net/manual/en/migration70.deprecated.php 


Might have been tired when reading it. Are old style constructors still 
available at all in PHP 7 (just deprecated)?? Looking for when old c

Re: [PHP-DEV] [RFC] [VOTE] Saner numeric strings

[Mark Randall]

On 16/07/2020 15:43, Nikita Popov wrote

I haven't backported any deprecation warnings to 7.4. Adding deprecations
to released versions is a hard no-go.


My apologies.

I'd got my wires crossed with seeing 
https://github.com/php/php-src/pull/3917 appear on the PRs.


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

Re: [PHP-DEV] [RFC] [VOTE] Saner numeric strings

[Nikita Popov]

On Thu, Jul 16, 2020 at 4:35 PM Mark Randall  wrote:

> On 16/07/2020 16:15, G. P. B. wrote:
> > I do agree that accepting trailing whitespace may be considered
> suboptimal
> > but as leading whitespaces don't even emit an E_NOTICE it is impossible
> to
> > drop this "feature".
>
> Didn't someone (Nikita?) already back-port a warning to 7.4 about some
> changes coming in 8.0?
>

I haven't backported any deprecation warnings to 7.4. Adding deprecations
to released versions is a hard no-go.

Regards,
Nikita

Re: [PHP-DEV] [RFC] [VOTE] Saner numeric strings

[Mark Randall]

On 16/07/2020 16:15, G. P. B. wrote:

I do agree that accepting trailing whitespace may be considered suboptimal
but as leading whitespaces don't even emit an E_NOTICE it is impossible to
drop this "feature".


Didn't someone (Nikita?) already back-port a warning to 7.4 about some 
changes coming in 8.0?


So it's not really impossible... it just takes the will to do it.

We can keep making small tweeks trying to make it better, or we can just 
do the "proper" thing, reject everything except exclusively 
properly-formatted numbers, and put the issue to bed permanently.


Mark Randall

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

Re: [PHP-DEV] [RFC] [VOTE] Saner numeric strings

[G. P. B.]

On Thu, 16 Jul 2020 at 15:39, Marco Pivetta  wrote:

> Hey George,
>
> I really like this specific bit of the proposal:
>
>  > And the various cases which currently emit an E_WARNING will be
> promoted to TypeErrors.
>
> I really do not like these particular horrible behaviors of the language
> (huge "yikes" for PHP being so broken):
>
>  * `"123" == "123 "` - do not want - already bad enough that leading
> whitespace is ignored here, and already caused some security issues on my
> end some years ago
>  * `is_numeric("123   ") === true` - `is_numeric()` should probably be
> soft-deprecated and replaced with something stricter, instead of expanding
> this too...
>
> I don't really care about `declare(strict_types=0), since I don't use it
> anymore, nor plan to use it anymore in any foreseeable future, but the two
> points above really feel wrong, and I'm conflicted about what to vote.
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>

Hey Marco,

I do agree that accepting trailing whitespace may be considered suboptimal
but as leading whitespaces don't even emit an E_NOTICE it is impossible to
drop this "feature".
Therefore I went for the next best thing which makes it IMHO sane, i.e.
accepting trailing whitespaces everywhere.

One way to improve the comparison case could be by adding an "eq" op like
PERL has which always do a string comparison,
basically equivalent to (string) $a === (string) $b as in PERL == always
does a numerical comparison, which is not the case in PHP as it tries to be
"smart".

To address the second point, deprecating is_numeric seems out of scope for
this RFC and could be a future scope.

Hope this clarifies some of the reasoning.

Best regards

George P. Banyard

Re: [PHP-DEV] [RFC] [VOTE] Saner numeric strings

[Marco Pivetta]

Hey George,

I really like this specific bit of the proposal:

 > And the various cases which currently emit an E_WARNING will be promoted
to TypeErrors.

I really do not like these particular horrible behaviors of the language
(huge "yikes" for PHP being so broken):

 * `"123" == "123 "` - do not want - already bad enough that leading
whitespace is ignored here, and already caused some security issues on my
end some years ago
 * `is_numeric("123   ") === true` - `is_numeric()` should probably be
soft-deprecated and replaced with something stricter, instead of expanding
this too...

I don't really care about `declare(strict_types=0), since I don't use it
anymore, nor plan to use it anymore in any foreseeable future, but the two
points above really feel wrong, and I'm conflicted about what to vote.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/


On Thu, Jul 16, 2020 at 3:21 PM G. P. B.  wrote:

> Hello internals,
>
> I've opened voting for the Saner Numeric strings RFC:
> https://wiki.php.net/rfc/saner-numeric-strings
>
> This will last 2 weeks until the 30th of July
>
> Best regards
>
> George P. Banyard
>

[PHP-DEV] [RFC] [VOTE] Saner numeric strings

[G. P. B.]

Hello internals,

I've opened voting for the Saner Numeric strings RFC:
https://wiki.php.net/rfc/saner-numeric-strings

This will last 2 weeks until the 30th of July

Best regards

George P. Banyard

Re: [PHP-DEV] Re: [RFC] Treat namespaced names as single token, relax reserved keyword restrictions

[Theodore Brown]

On Thu, July 16 2020 at 3:04 AM Nikita Popov  wrote:

> While I don't think anyone had plans to mix whitespace, this is
> indicative of a larger issue. While I'm one of the people who voted
> for @@ as my first choice before, I wouldn't do so now (even with
> this RFC accepted). This issue made me realize that there is more at
> stake here than just "which syntax is prettier?" and choices that
> have a "closing tag" are technically more favorable, especially if
> we consider future extensions of the attribute system that may
> introduce additional ambiguities (e.g., Rust allows placing
> attributes pretty much everywhere in code -- how sure are we that
> there will be no unanticipated ambiguities?)

Hi Nikita,

Can you think of an example that would cause an ambiguity even when
namespaced names are treated as tokens? As I understand it, there
can't be an ambiguity, since there would always be an attribute token
followed by a class name token. It should be possible to put this
anywhere it makes sense without ambiguities.

Other languages like Java allow attributes/annotations in more places
than PHP (e.g. on variables) and the @ syntax doesn't prevent this.

Theodore

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

Re: [PHP-DEV] Re: [RFC] Nullsafe operator

[Ilija Tovilo]

Hi internals

> > https://wiki.php.net/rfc/nullsafe_operator
>
> Unfortunately, we have found some new edge cases that are currently
> not handled.

So, we've decided to completely disallow the nullsafe operator in
write context. This means you can no longer use it on the left hand
side of an assignment. This change was made mostly due to technical
issues but some of the semantics were also not completely clear (e.g.
do we always execute the right hand side? which order? etc).

You can find a diff of the changes here:
https://github.com/iluuu1994/nullsafe-operator-rfc/compare/5df9d041d2d202e5fab02b5881f2c4dc1fd9bcce...v1

I realize that it's very much last-minute but I will be opening the
vote tomorrow unless there are any objections. This way we have a few
days to merge before the feature freeze if the RFC is accepted.

Ilija

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

Re: [PHP-DEV] Re: [RFC] Treat namespaced names as single token, relax reserved keyword restrictions

[Nicolas Grekas]

> > > > I have reduced the scope of this RFC to handle just the issue of
> > > > namespaced names, without touching any other reserved keyword
> > restrictions.
> > > > As the discussion shows, those are trickier, with more cases of
> > perceived
> > > > ambiguity that may need to be mitigated.
> > > >
> > > > As this proposal is now a prerequisite for
> > > > https://wiki.php.net/rfc/shorter_attribute_syntax, I have heard
> from a
> > > > disturbing number of people that they might vote against this
> > proposal, not
> > > > because they disagree with it, but because that would prevent the
> > adoption
> > > > of the @@ attribute syntax. I'm not sure what to do about that...
> > > >
> > >
> > > Heads up: I plan to open voting on this proposal tomorrow, unless there
> > is
> > > further feedback.
> >
> > One possibility would be to split it up into two separate RFCs:
> > (This would probably be too short notice, and this isn't similar to any
> > proposal in the past)
> >
> > 1. An Yes/No RFC requiring a 2/3 majority for accepting the amended `@@`
> > attribute syntax with the restriction the original RFC proposed (no
> > whitespace&reserved words.
> >
> >I'd think that very few proponents of `@@` had plans to mix whitespace
> > with backslashes in attributes when reading that RFC, and it's extremely
> > similar to the original attribute syntax change RFC.
> >
>
> While I don't think anyone had plans to mix whitespace, this is indicative
> of a larger issue. While I'm one of the people who voted for @@ as my first
> choice before, I wouldn't do so now (even with this RFC accepted). This
> issue made me realize that there is more at stake here than just "which
> syntax is prettier?" and choices that have a "closing tag" are technically
> more favorable, especially if we consider future extensions of the
> attribute system that may introduce additional ambiguities (e.g., Rust
> allows placing attributes pretty much everywhere in code -- how sure are we
> that there will be no unanticipated ambiguities?)
>
> Probably the most unambiguous treatment here would be to simply rerun the
> vote on the short attribute syntax after this RFC is decided one way or
> another, but that would be quite a bit of process overhead, for what is a
> small issue to most people.
>
>
> > 2. A yes/no RFC for this RFC to affect everything except the choice of
> > attribute syntax.
> >(i.e. if 2 passes but not 1, we'd end up using `<>` in
> > 8.0 and forbidding `<>`)
> >
>
> Just to be clear, the whitespace issue affects only the @@ syntax, not the
> <<>> or #[] syntaxes.
>

It is my understanding that implementation concerns are a valid reason to
invalidate a vote, especially when they are found after the vote happened.

If we really want to keep the @@ syntax, there might still be a way: the
syntax could require using brackets after the attribute name:

@@Foo => @@Foo()

But I voted for #[Foo] so I'm not preaching my own preference by making
this suggestion ;)

Nicolas

Re: [PHP-DEV] Re: [RFC] Treat namespaced names as single token, relax reserved keyword restrictions

[Peter Bowyer]

On Thu, 16 Jul 2020 at 09:04, Nikita Popov  wrote:

> While I don't think anyone had plans to mix whitespace, this is indicative
> of a larger issue. While I'm one of the people who voted for @@ as my first
> choice before, I wouldn't do so now (even with this RFC accepted). This
> issue made me realize that there is more at stake here than just "which
> syntax is prettier?" and choices that have a "closing tag" are technically
> more favorable, especially if we consider future extensions of the
> attribute system that may introduce additional ambiguities (e.g., Rust
> allows placing attributes pretty much everywhere in code -- how sure are we
> that there will be no unanticipated ambiguities?)
>

Thanks for this clear explainer. I hadn't appreciated the "no closing
delimiter" issues during the original vote, also picking @@.

As many other languages use '@' as their symbol, how do they handle or
avoid the whitespace issues?

Peter

Re: [PHP-DEV] Re: [RFC] Treat namespaced names as single token, relax reserved keyword restrictions

[Nikita Popov]

On Thu, Jul 16, 2020 at 3:40 AM tyson andre 
wrote:

> > > I have reduced the scope of this RFC to handle just the issue of
> > > namespaced names, without touching any other reserved keyword
> restrictions.
> > > As the discussion shows, those are trickier, with more cases of
> perceived
> > > ambiguity that may need to be mitigated.
> > >
> > > As this proposal is now a prerequisite for
> > > https://wiki.php.net/rfc/shorter_attribute_syntax, I have heard from a
> > > disturbing number of people that they might vote against this
> proposal, not
> > > because they disagree with it, but because that would prevent the
> adoption
> > > of the @@ attribute syntax. I'm not sure what to do about that...
> > >
> >
> > Heads up: I plan to open voting on this proposal tomorrow, unless there
> is
> > further feedback.
>
> One possibility would be to split it up into two separate RFCs:
> (This would probably be too short notice, and this isn't similar to any
> proposal in the past)
>
> 1. An Yes/No RFC requiring a 2/3 majority for accepting the amended `@@`
> attribute syntax with the restriction the original RFC proposed (no
> whitespace&reserved words.
>
>I'd think that very few proponents of `@@` had plans to mix whitespace
> with backslashes in attributes when reading that RFC, and it's extremely
> similar to the original attribute syntax change RFC.
>

While I don't think anyone had plans to mix whitespace, this is indicative
of a larger issue. While I'm one of the people who voted for @@ as my first
choice before, I wouldn't do so now (even with this RFC accepted). This
issue made me realize that there is more at stake here than just "which
syntax is prettier?" and choices that have a "closing tag" are technically
more favorable, especially if we consider future extensions of the
attribute system that may introduce additional ambiguities (e.g., Rust
allows placing attributes pretty much everywhere in code -- how sure are we
that there will be no unanticipated ambiguities?)

Probably the most unambiguous treatment here would be to simply rerun the
vote on the short attribute syntax after this RFC is decided one way or
another, but that would be quite a bit of process overhead, for what is a
small issue to most people.


> 2. A yes/no RFC for this RFC to affect everything except the choice of
> attribute syntax.
>(i.e. if 2 passes but not 1, we'd end up using `<>` in
> 8.0 and forbidding `<>`)
>

Just to be clear, the whitespace issue affects only the @@ syntax, not the
<<>> or #[] syntaxes.

Nikita

Still, my proposal seems like a dissatisfying one.
>
> Allowing future 3+-way votes to be re-voted once due to unexpected
> implementation concerns
> (when the original authors are among the authors of the amendment)
> with a 50% majority requirement (instead of 2/3) might help in the future,
> but would probably entail its own process vote for an extremely
> rare/narrow RFC situation.
> That wouldn't help with this RFC due to the feature freeze,
> and I think that situation's too rare to actually work out details and
> actually propose that amendment.
>
> P.S. I'm in favor of removing whitespace between tokens of names.
>
> - Tyson

Re: [PHP-DEV] [RFC] Saner string to number comparisons

[Nikita Popov]

On Thu, Jul 16, 2020 at 9:21 AM Brent Roose  wrote:

> Hey Nikita
>
> Thanks for the rebase. I just tested this on one of our most largest
> projects (after verifying that the warning does show in a dummy test case),
> and all is fine. So from my point of view, there is a theoretical chance of
> breaking code, but I believe this won't have a large impact, at least not
> on modern-day projects.
>
> Kind regards
> Brent
>

Great to hear, thanks for testing!

Regards,
Nikita

On 15 Jul 2020, at 11:10, Nikita Popov  wrote:
>
> On Wed, Jul 15, 2020 at 10:56 AM Brent Roose  wrote:
>
> Hi Nikita
>
> Yes that would be nice, if it's not too much of a hassle. I'm only able to
> test this in one or two large Laravel projects, so it would still be a
> limited test.
>
> Kind regards
> Brent
>
>
> Done! https://github.com/php/php-src/pull/3917 is now based on current 7.4
> HEAD. Note that it just unconditionally throws a warning, without a way to
> disable it.
>
> Nikita
>
> On 15 Jul 2020, at 10:53, Nikita Popov  wrote:
>
> On Wed, Jul 15, 2020 at 10:49 AM Brent Roose  wrote:
>
> Hi Nikita
>
> Is the ini setting available in current 7.4 builds? Is it documented
> somewhere? I'd like to test this change in some of our projects.
>
>
> We did not introduce an ini setting in PHP 7.4, I only used it for my own
> experiments. The implementation is available at
> https://github.com/php/php-src/pull/3917. I could rebase that to current
> 7.4 if that would be useful.
>
> Nikita
>
> On 15 Jul 2020, at 10:28, Nikita Popov  wrote:
>
> On Tue, Jul 14, 2020 at 11:47 PM Björn Larsson 
>
> wrote:
>
> Den 2020-07-14 kl. 15:48, skrev Nikita Popov:
>
> On Thu, Jul 2, 2020 at 10:09 AM Nikita Popov 
>
> wrote:
>
>
> On Mon, Mar 4, 2019 at 6:00 PM Nikita Popov 
>
> wrote:
>
>
> On Wed, Feb 27, 2019 at 10:23 AM Zeev Suraski  wrote:
>
>
> On Tue, Feb 26, 2019 at 2:27 PM Nikita Popov 
> wrote:
>
> Hi internals,
>
> I think it is well known that == in PHP is a pretty big footgun. It
> doesn't
> have to be. I think that type juggling comparisons in a language like
> PHP
> have some merit, it's just that the particular semantics of == in PHP
> make
> it so dangerous. The biggest WTF factor is probably that 0 ==
>
> "foobar"
>
> returns true.
>
> I'd like to bring forward an RFC for PHP 8 to change the semantics
>
> of ==
>
> and other non-strict comparisons, when used between a number and a
> string:
>
> https://wiki.php.net/rfc/string_to_number_comparison
>
> The tl;dr is that if you compare a number and a numeric string,
>
> they'll
>
> be
> compared as numbers. Otherwise, the number is converted into a string
> and
> they'll be compared as strings.
>
> This is a very significant change -- not so much because the actual
>
> BC
>
> breakage is expected to be particularly large, but because it is a
> silent
> change in core language semantics, which makes it hard to determine
> whether
> or not code is affected by the change. There are things we can do
>
> about
>
> this, for example the RFC suggests that we might want to have a
> transition
> mode where we perform the comparison using both the old and the new
> semantics and warn if the result differs.
>
> I think we should give serious consideration to making such a change.
> I'd
> be interested to hear whether other people think this is worthwhile,
>
> and
>
> how we could go about doing it, while minimizing breakage.
>
> I generally like the direction and think we should seriously consider
>
> it.
>
>
> I think that before we make any decisions on this, or even dive too
>
> deep
>
> into the discussion - we actually need to implement this behavior,
> including the proposed INI setting you mentioned we might add in 7.4
>
> - and
>
> see what happens in some real world apps, at least in terms of
>
> potential
>
> danger (as you say, figuring out whether there's actual breakage would
> require a full audit of every potentially problematic sample.
>
> Ultimately,
>
> I think there's no question that if we were to start from scratch,
>
> we'd be
>
> going for something along these lines.  But since we're not starting
>
> from
>
> scratch - scoping the level of breakage is key here.
>
> Zeev
>
> Totally agree that assessing the amount of breakage in real code is key
> here. I have now implemented a warning for PHP 7.4 (for now
>
> unconditional,
>
> no ini setting) that is thrown whenever the result of a comparison is
>
> going
>
> to change under the currently proposed rules:
> https://github.com/php/php-src/pull/3917
>
> I've done a few initial tests by running this against the Laravel,
> Symfony and pear-core. The warning was thrown 2 times for Laravel, 1
>
> times
>
> for Symfony and 2 times for pear-core. (See PR for the results.)
>
> Both of the warnings in pear-core pointed to implementation bugs. The
> Symfony warning was due to trailing whitespace not being allowed in
>
> numeric
>
> strings (something we should definitely change). One of the Laravel
> warnings is ultimately a false-positi

Re: [PHP-DEV] [RFC] Saner string to number comparisons

[Nikita Popov]

On Wed, Jul 15, 2020 at 5:12 PM Arnold Daniels 
wrote:

> Hi Nikita,
>
> One of the problems with numeric string comparisons is that it might
> interpret a hexadecimal value as scientific notation
>
> $red = '99';
> $purple = '9900e2';
> $red == $purple; // true
>
> I suggest only interpreting a number formatted with a sign ("1e+100") or
> with decimals ("1.0e100") as scientific notation as part of this RFC. These
> are the notations that languages use when casting a float to a string,
> never "1e100"
>
> PHP "1.0E+100"
> JavaScript "1e+100"
> Python "1e+100"
> Ruby "1.0e+100"
> Java "1.0E100"
>
> Arnold
>

Hey Arnold,

I don't want to include this change in this RFC (because the proposal does
not otherwise touch string-to-string comparison at all), but I do think
this is a very good idea. I was not aware of this particular variant of the
issue (i.e., that it also occurs with prefixes other than "0e") and this
seems like a pragmatic way to resolve that particular ambiguity. A question
here would be whether to make this something specific to string-to-string
comparisons, or make a general change to numeric string recognition (i.e.,
no longer treat "1e100" as a numeric string, only "1.0e100" or "1e+100".)

Regards,
Nikita

Re: [PHP-DEV] [RFC] Saner string to number comparisons

[Brent Roose]

Hey Nikita

Thanks for the rebase. I just tested this on one of our most largest projects 
(after verifying that the warning does show in a dummy test case), and all is 
fine. So from my point of view, there is a theoretical chance of breaking code, 
but I believe this won't have a large impact, at least not on modern-day 
projects.

Kind regards
Brent

> On 15 Jul 2020, at 11:10, Nikita Popov  wrote:
> 
> On Wed, Jul 15, 2020 at 10:56 AM Brent Roose  > wrote:
> 
>> Hi Nikita
>> 
>> Yes that would be nice, if it's not too much of a hassle. I'm only able to
>> test this in one or two large Laravel projects, so it would still be a
>> limited test.
>> 
>> Kind regards
>> Brent
>> 
> 
> Done! https://github.com/php/php-src/pull/3917 
>  is now based on current 7.4
> HEAD. Note that it just unconditionally throws a warning, without a way to
> disable it.
> 
> Nikita
> 
>> On 15 Jul 2020, at 10:53, Nikita Popov > > wrote:
>> 
>> On Wed, Jul 15, 2020 at 10:49 AM Brent Roose > > wrote:
>> 
>>> Hi Nikita
>>> 
>>> Is the ini setting available in current 7.4 builds? Is it documented
>>> somewhere? I'd like to test this change in some of our projects.
>>> 
>> 
>> We did not introduce an ini setting in PHP 7.4, I only used it for my own
>> experiments. The implementation is available at
>> https://github.com/php/php-src/pull/3917 
>> . I could rebase that to current
>> 7.4 if that would be useful.
>> 
>> Nikita
>> 
>>> On 15 Jul 2020, at 10:28, Nikita Popov >> > wrote:
>>> 
>>> On Tue, Jul 14, 2020 at 11:47 PM Björn Larsson >> 
 
>>> wrote:
>>> 
>>> Den 2020-07-14 kl. 15:48, skrev Nikita Popov:
>>> 
>>> On Thu, Jul 2, 2020 at 10:09 AM Nikita Popov >> >
>>> 
>>> wrote:
>>> 
>>> 
>>> On Mon, Mar 4, 2019 at 6:00 PM Nikita Popov >> >
>>> 
>>> wrote:
>>> 
>>> 
>>> On Wed, Feb 27, 2019 at 10:23 AM Zeev Suraski >> > wrote:
>>> 
>>> 
>>> On Tue, Feb 26, 2019 at 2:27 PM Nikita Popov >> >
>>> wrote:
>>> 
>>> Hi internals,
>>> 
>>> I think it is well known that == in PHP is a pretty big footgun. It
>>> doesn't
>>> have to be. I think that type juggling comparisons in a language like
>>> PHP
>>> have some merit, it's just that the particular semantics of == in PHP
>>> make
>>> it so dangerous. The biggest WTF factor is probably that 0 ==
>>> 
>>> "foobar"
>>> 
>>> returns true.
>>> 
>>> I'd like to bring forward an RFC for PHP 8 to change the semantics
>>> 
>>> of ==
>>> 
>>> and other non-strict comparisons, when used between a number and a
>>> string:
>>> 
>>> https://wiki.php.net/rfc/string_to_number_comparison 
>>> 
>>> 
>>> The tl;dr is that if you compare a number and a numeric string,
>>> 
>>> they'll
>>> 
>>> be
>>> compared as numbers. Otherwise, the number is converted into a string
>>> and
>>> they'll be compared as strings.
>>> 
>>> This is a very significant change -- not so much because the actual
>>> 
>>> BC
>>> 
>>> breakage is expected to be particularly large, but because it is a
>>> silent
>>> change in core language semantics, which makes it hard to determine
>>> whether
>>> or not code is affected by the change. There are things we can do
>>> 
>>> about
>>> 
>>> this, for example the RFC suggests that we might want to have a
>>> transition
>>> mode where we perform the comparison using both the old and the new
>>> semantics and warn if the result differs.
>>> 
>>> I think we should give serious consideration to making such a change.
>>> I'd
>>> be interested to hear whether other people think this is worthwhile,
>>> 
>>> and
>>> 
>>> how we could go about doing it, while minimizing breakage.
>>> 
>>> I generally like the direction and think we should seriously consider
>>> 
>>> it.
>>> 
>>> 
>>> I think that before we make any decisions on this, or even dive too
>>> 
>>> deep
>>> 
>>> into the discussion - we actually need to implement this behavior,
>>> including the proposed INI setting you mentioned we might add in 7.4
>>> 
>>> - and
>>> 
>>> see what happens in some real world apps, at least in terms of
>>> 
>>> potential
>>> 
>>> danger (as you say, figuring out whether there's actual breakage would
>>> require a full audit of every potentially problematic sample.
>>> 
>>> Ultimately,
>>> 
>>> I think there's no question that if we were to start from scratch,
>>> 
>>> we'd be
>>> 
>>> going for something along these lines.  But since we're not starting
>>> 
>>> from
>>> 
>>> scratch - scoping the level of breakage is key here.
>>> 
>>> Zeev
>>> 
>>> Totally agree that assessing the amount of breakage in real code is key
>>> here. I have now implemented a warning for PHP 7.4 (for now
>>> 
>>> unconditional,
>>> 
>>> n