[PHP-DEV] Re: [RFC] Stricter type-checks for arithmetic/bitwise operators

[Terje Slettebø]

Nikita Popov wrote:


I would like to propose making the use of arithmetic/bitwise operators
on arrays, resources and (non-overloaded) objects a TypeError
exception:

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

This is inspired by some of the recent discussions, in particular the
operator overloading RFC (where the fact that operations on
non-overloaded objects still succeed with just a notice was
criticized) and the increment/decrement RFC, which handles the array
case of this proposal for inc/dec only.

I think as-is, this RFC should be completely uncontroversial. However,
there is an open question on whether we want to make this slightly
more strict, in order to align the semantics with the rules for weak
parameter type checks for ints/floats.

If we do that, then this RFC could be a stepping stone towards making
"implicit" internal casts use the (weak) parameter type checking
semantics more generally, which I think would be a good idea. The
current explicit cast semantics we use everywhere are too forgiving
for most circumstances (e.g. an array is almost always not a
reasonable input where an integer is expected).


I definitely support this proposal, and I'd love the "strict_operators" directive 
as well, but that's a different proposal, and a different discussion.


The current proposal seems, in the words of the proposal, to be pretty uncontroversial: 
It basically corrects a bunch of WTFs in PHP's type system.


Regards,

Terje



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

Re: [PHP-DEV] [RFC] switch expression

[Terje Slettebø]

Larry Garfield wrote:


On Sun, Mar 29, 2020, at 4:04 PM, Ilija Tovilo wrote:

What you're proposing is a language construct for an *expression*,
which evaluates depending on internal logic to a different value.

Those are sufficiently distinct that I agree they should have distinct
keywords.  Plus, the internal syntax is non-trivial to switch back and
forth between (break vs not, etc.), so it is misleading for people to
present them as two slight variants on the same thing; they're really
quite distinct, and that's OK.

My recommendation would be to just borrow Rust's keyword:

$result = match ($var) {
$expression => $expression;
$expression => $expression;
$expression => $expression;
default => $expression;
}


I would tend to side with this. The way I'd interpret this is that the provided 
value is matched against the value of each expression, which also means arbitrary 
comparisons may be used without additional syntax or special cases, as has 
been mentioned in this thread:


$temp=get_temperature();

$phase = match(true)
{
 $temp<0 => "Ice",
 $temp>=0 && $temp<=100 => "Water",
 $temp>100 => "Steam"
}

I also agree that we should keep this as an expression, not extending it 
to be a statement as well. Keep it simple. Should we want to use it as a 
statement at a later point, that would be possible to add.


I also like the exhaustive check, so that the following would give an error 
(and could be found using static analysis) about not handling other values 
than 1-3:


$result = match($x) // int
{
 1 => ...,
 2 => ...,
 3 => ...
}

Having a new keyword like this opens the door to further changes that moves 
it away from the way switch works, such as pattern matching and destructuring.


Regards,

Terje



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

Re: [PHP-DEV] [RFC] Constructor Property Promotion

[Nikita Popov]

On Thu, Apr 2, 2020 at 3:47 PM Markus Fischer  wrote:

> Him
>
> On 02.04.20 12:07, Nikita Popov wrote:
> > Reflection will see the state after desugaring. That is, it just sees
> > normal properties and normal constructor args. I've made this more
> explicit
> > in the RFC now:
> https://wiki.php.net/rfc/constructor_promotion#reflection
>
> Thanks!
>
> Another one, also related a bit to your PHP-Parser (?): will the
> tokenization process "see" the code before desugaring?
>
> I'm wondering how automated translation tool can detect that a certain
> code is not "sugared" and promote this?
>

Tokenization and parsing both happen before the desugaring, they see the
code in its original form. They would detect promoted properties by
checking whether a constructor parameter has a visibility modifier.  Of
course, tooling might want to perform the desugaring transformation
internally, so it sees a uniform representation of everything.

Regards,
Nikita

Re: [PHP-DEV] [RFC] Constructor Property Promotion

[Markus Fischer]

Him

On 02.04.20 12:07, Nikita Popov wrote:

Reflection will see the state after desugaring. That is, it just sees
normal properties and normal constructor args. I've made this more explicit
in the RFC now: https://wiki.php.net/rfc/constructor_promotion#reflection


Thanks!

Another one, also related a bit to your PHP-Parser (?): will the 
tokenization process "see" the code before desugaring?


I'm wondering how automated translation tool can detect that a certain 
code is not "sugared" and promote this?


thanks!
- Markus

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

Re: [PHP-DEV] [RFC] Stricter type-checks for arithmetic/bitwise operators

[Rowan Tommins]

Hi Nikita,

On Thu, 2 Apr 2020 at 09:14, Nikita Popov  wrote:

> I would like to propose making the use of arithmetic/bitwise operators on
> arrays, resources and (non-overloaded) objects a TypeError exception:
>
> https://wiki.php.net/rfc/arithmetic_operator_type_checks
>


Thanks for writing this up; one of the conclusions when revising my inc/dec
RFC was that this should be proposed, but I've not had the energy to follow
through.

Discovering that objects become int(1) was a big WTF for me. I'd happily
see that throw an error even under an explicit cast - "(string)new class{}"
is currently an Error, but "(int)new class{}" and "(float)new class{}" are
only a Notice.Would it be possible to throw an Error in this case without
fixing the comparison operator quirk you noted in rfc/engine_warnings?

I initially thought resources made sense as they are, but like you I
concluded that the only real use is to get the ID itself, so explicit casts
are enough. There's a possibility that someone used to JS might write
$resource+0 instead of (int)$resource out of habit, but it doesn't seem
particularly likely, and is easy to fix. get_resource_id() is a good idea,
too; for similar reasons, I've often wished objects with __toString()
aliased it to a more specific method, rather than it being the only way to
get a certain representation.

While the behaviour of other types such as strings would be nice to
revisit, I think it's worth keeping this RFC to arrays, objects, and
resources, because other cases have a lot more to consider in terms of
detail and backward compatibility impact.

Regards,
-- 
Rowan Tommins
[IMSoP]

[PHP-DEV] PHP 7.4.5RC1 is available for testing

[Derick Rethans]

PHP 7.4.5RC1 has just been released and can be downloaded from:



Or use the git tag: php-7.4.5RC1

Windows binaries are available at: 

Please test it carefully, and report any bugs in the bug system at
.

Hash values and PGP signatures can be found below or at
.

7.4.5 should be expected in 2 weeks, i.e. on April 16th, 2020.

Thank you, and happy testing!

Regards,
Derick Rethans


php-7.4.5RC1.tar.gz
SHA256 hash: 86e4b0124fc05bedba0b9b40dadb605875066f09eac759e59922bf39f9290fae
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAl6DS8IACgkQkQ3rRvU+
oxKOzhAAyb9ZRa1GsRRWO3jxJpcRdeNW/SO5Z+jDRX3YuwPn3WM6mQJFwNLfNFjc
GMvqvSAsxuQSl9PZvv7fJgZjzw1rZUAVYYCeecUXfuSh3jHENjRDC84cq0wkKhv6
SAf0VVBBuIOvBEln/1mQqaqQpUD5lHInR1Xpgx97kEUMq+nVBN17PTn/PYfo+w0E
HI0Hwh6wBZfQOlkvtOraK+i1v9MzgoL1/KFOv72iEnyzKkXP24aUk4GhEhtgJAX3
mZ6il1hst9IHoWeS7u4x3kMtexdN6H6N88s6x2OE4C0XC8W5HsamPRdTYxMX2ufH
GTjn4kG1cZxA8Tbw0deO0V1NH2JYQuSZl2OesHNZ1gCRU+vMAnDAxBqEc2PhCqx4
niG7QNvgGOgFCReE20h4+k16fKO7CqDbQ4Ceb2LvHH+ZlYHV0gR8TlReEh0MWBRB
4QmGY+3Rwq9MF84046gHY1B2zJwNNpQ3xqjGUemefztZLrx7z1l3engvMzVdMbEq
GbhI7h+lDvpGUo7GDIDBPKZyefp/yUXbTr/fnltIAKq/m2mq+IE65NM+pnSRv4ni
GCxtpm39qSdjnrKhP4wHpgXBoVe9b00SYfSzVq040xyHqDUi7ShMI9P8JZcv6Ur9
5ZZFziWQj7m1OiOmB4C8HVVJJgrPBoyKGlCdtWQCHZqfvTSKjYg=
=24Cr
-END PGP SIGNATURE-

php-7.4.5RC1.tar.bz2
SHA256 hash: 051da6c3127e03ca85aab098501009d36999a12263d6cb142efea042ab94760d
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAl6DS8YACgkQkQ3rRvU+
oxKSyhAAtrWr1zMtuzQNknPbaeKw4D5NZWfk2qI79cbqR8QzNmcJVnwPwJ+iyKsp
qouGJBRtHUuJPFOQI4HicLRjOp9di+hkgG/WTuJDbtV9PGw7tImbCDw5scz68WaY
you+F4Vcrbr91Mh9JgODjnG3anUJU4fMhzI/KVjW1RuRtNkwYZrABX3ud5zj/9iT
42b+6VNSmmaGERio5qzcgfTg2UvDX09siTbIoz/SiBGaf/EWPVswEvjG1rVKBhd1
kbAVEqdGg0MlZ2eQGx+buSPHLuUm204gQvi6dI85ace8ill+U0lgYc0Vsc0KCNLp
6umnZXmJ0Rvf2fkJwAJJgmG2CjZejfPhSzIkYcJwjlogcW6E3RcHbuFsGF9A9FLP
9LcONfgFbVs6KZMjDJ1YjyMcMnEMsX3txFA6qu+AcnazyfzbAh8HDrVd04cZxISX
tR6lthvN8aTeiOPoUHhTxWtogR40kkOU97/KPdK8wLkZM3VjlrCEQ6SxXL2u17rm
sep/zHybNO5IVl6PGbfMlRFf0TYfErUZH6aSew0wwW8e6lj+L98Phke1J5sWCSHd
W26N57F+c8tcIUXNfg7xEoJzF+UvPSySFmDcIWl/xBLD4MJsVUVTYZptpdrvcigx
6QPOvcQFbX0mB3SjrpDm4LUyIG//1z7jE9b7cwuPbK1NRd5iPNY=
=Ipsx
-END PGP SIGNATURE-

php-7.4.5RC1.tar.xz
SHA256 hash: 2141c39d21ab792e3a77f1303f388ac566d3f8666533ff140cd6935e6087d5b1
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAl6DS8cACgkQkQ3rRvU+
oxL6xhAAyUEpz0aFWqRyqnsQ+J1Gf/Mf35Q25mkQl/86cGz4fif64qk2jyP/+H9+
vjdfRQvbbcWbbt8BWq0OKgiDMUEaFRCinJK8oiWAFng3Q+dw8ttyH7e6KEuxQyCC
VwosSJkQ1EqwdBGoJMpYXlhBlGxmUlRvnbvWPlzKsiUBajIF/TUbHu3WnXG2cWW8
+HAlhYmlcm9cYXeUY1VIiL0FiuDW6i4NnWxaWQpIsUpp1G2KwxFFwacM8wugljQh
kZlqyH9zy4tvWZLpUh7ynV8ij3mmi0OhszdDu5oF9YwLZ3zq8tiT1yL+DND/BAeo
3/6TuJ4Qa2wwbh8Exmyf9FfkB1H3W7CUQfqdFecF8w6SYiFEapSEABfH3gRI/YdY
aTAigoR+JqHg0E1LI0rkZRF7E0OR10VTJ9G7rW1qUpCfnQIGkGg2lX4FEREatlJd
z0O7yBaYqnuiMoLBumT/Aacm7ILJkxvJ3XccMR0JJ/7yLW6/gBqQvbCrfqwd+QWw
1EfEcOqxE8p+BDP9Z8E5p3u5XlsXhorqqbBp5syudIaVu9fmO/qbg/2G0j2elqek
g5Ww8V99etmYaUr+O+su4+Z5pUqcQ8cyeTJeq6q6pxFYwPVEF7wUpMF6kDDaBwMs
rP3dQgZZ3/iBnZbq5HAgu51dqwqPrgsRfYIjbKuaXVvTLLU4kv0=
=cTJf
-END PGP SIGNATURE-

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

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

[PHP-DEV] PHP 7.4.5RC1 Announced!!

[Derick Rethans]

Hi,

tarballs are in https://downloads.php.net/~derick or use the
php-7.4.5RC1 tag.

Signatures/hashes on
 and below.

The announce is planned for Thursday, April 2nd.

Thanks,
Derick

php-7.4.5RC1.tar.gz
SHA256 hash: 86e4b0124fc05bedba0b9b40dadb605875066f09eac759e59922bf39f9290fae
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAl6DS8IACgkQkQ3rRvU+
oxKOzhAAyb9ZRa1GsRRWO3jxJpcRdeNW/SO5Z+jDRX3YuwPn3WM6mQJFwNLfNFjc
GMvqvSAsxuQSl9PZvv7fJgZjzw1rZUAVYYCeecUXfuSh3jHENjRDC84cq0wkKhv6
SAf0VVBBuIOvBEln/1mQqaqQpUD5lHInR1Xpgx97kEUMq+nVBN17PTn/PYfo+w0E
HI0Hwh6wBZfQOlkvtOraK+i1v9MzgoL1/KFOv72iEnyzKkXP24aUk4GhEhtgJAX3
mZ6il1hst9IHoWeS7u4x3kMtexdN6H6N88s6x2OE4C0XC8W5HsamPRdTYxMX2ufH
GTjn4kG1cZxA8Tbw0deO0V1NH2JYQuSZl2OesHNZ1gCRU+vMAnDAxBqEc2PhCqx4
niG7QNvgGOgFCReE20h4+k16fKO7CqDbQ4Ceb2LvHH+ZlYHV0gR8TlReEh0MWBRB
4QmGY+3Rwq9MF84046gHY1B2zJwNNpQ3xqjGUemefztZLrx7z1l3engvMzVdMbEq
GbhI7h+lDvpGUo7GDIDBPKZyefp/yUXbTr/fnltIAKq/m2mq+IE65NM+pnSRv4ni
GCxtpm39qSdjnrKhP4wHpgXBoVe9b00SYfSzVq040xyHqDUi7ShMI9P8JZcv6Ur9
5ZZFziWQj7m1OiOmB4C8HVVJJgrPBoyKGlCdtWQCHZqfvTSKjYg=
=24Cr
-END PGP SIGNATURE-

php-7.4.5RC1.tar.bz2
SHA256 hash: 051da6c3127e03ca85aab098501009d36999a12263d6cb142efea042ab94760d
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAl6DS8YACgkQkQ3rRvU+
oxKSyhAAtrWr1zMtuzQNknPbaeKw4D5NZWfk2qI79cbqR8QzNmcJVnwPwJ+iyKsp
qouGJBRtHUuJPFOQI4HicLRjOp9di+hkgG/WTuJDbtV9PGw7tImbCDw5scz68WaY
you+F4Vcrbr91Mh9JgODjnG3anUJU4fMhzI/KVjW1RuRtNkwYZrABX3ud5zj/9iT
42b+6VNSmmaGERio5qzcgfTg2UvDX09siTbIoz/SiBGaf/EWPVswEvjG1rVKBhd1
kbAVEqdGg0MlZ2eQGx+buSPHLuUm204gQvi6dI85ace8ill+U0lgYc0Vsc0KCNLp
6umnZXmJ0Rvf2fkJwAJJgmG2CjZejfPhSzIkYcJwjlogcW6E3RcHbuFsGF9A9FLP
9LcONfgFbVs6KZMjDJ1YjyMcMnEMsX3txFA6qu+AcnazyfzbAh8HDrVd04cZxISX
tR6lthvN8aTeiOPoUHhTxWtogR40kkOU97/KPdK8wLkZM3VjlrCEQ6SxXL2u17rm
sep/zHybNO5IVl6PGbfMlRFf0TYfErUZH6aSew0wwW8e6lj+L98Phke1J5sWCSHd
W26N57F+c8tcIUXNfg7xEoJzF+UvPSySFmDcIWl/xBLD4MJsVUVTYZptpdrvcigx
6QPOvcQFbX0mB3SjrpDm4LUyIG//1z7jE9b7cwuPbK1NRd5iPNY=
=Ipsx
-END PGP SIGNATURE-

php-7.4.5RC1.tar.xz
SHA256 hash: 2141c39d21ab792e3a77f1303f388ac566d3f8666533ff140cd6935e6087d5b1
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAl6DS8cACgkQkQ3rRvU+
oxL6xhAAyUEpz0aFWqRyqnsQ+J1Gf/Mf35Q25mkQl/86cGz4fif64qk2jyP/+H9+
vjdfRQvbbcWbbt8BWq0OKgiDMUEaFRCinJK8oiWAFng3Q+dw8ttyH7e6KEuxQyCC
VwosSJkQ1EqwdBGoJMpYXlhBlGxmUlRvnbvWPlzKsiUBajIF/TUbHu3WnXG2cWW8
+HAlhYmlcm9cYXeUY1VIiL0FiuDW6i4NnWxaWQpIsUpp1G2KwxFFwacM8wugljQh
kZlqyH9zy4tvWZLpUh7ynV8ij3mmi0OhszdDu5oF9YwLZ3zq8tiT1yL+DND/BAeo
3/6TuJ4Qa2wwbh8Exmyf9FfkB1H3W7CUQfqdFecF8w6SYiFEapSEABfH3gRI/YdY
aTAigoR+JqHg0E1LI0rkZRF7E0OR10VTJ9G7rW1qUpCfnQIGkGg2lX4FEREatlJd
z0O7yBaYqnuiMoLBumT/Aacm7ILJkxvJ3XccMR0JJ/7yLW6/gBqQvbCrfqwd+QWw
1EfEcOqxE8p+BDP9Z8E5p3u5XlsXhorqqbBp5syudIaVu9fmO/qbg/2G0j2elqek
g5Ww8V99etmYaUr+O+su4+Z5pUqcQ8cyeTJeq6q6pxFYwPVEF7wUpMF6kDDaBwMs
rP3dQgZZ3/iBnZbq5HAgu51dqwqPrgsRfYIjbKuaXVvTLLU4kv0=
=cTJf
-END PGP SIGNATURE-

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

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

[PHP-DEV] Re: [RFC] Stricter type-checks for arithmetic/bitwise operators

[Andrea Faulds]

Hi Nikita,

Nikita Popov wrote:

Hi internals,

I would like to propose making the use of arithmetic/bitwise operators on
arrays, resources and (non-overloaded) objects a TypeError exception:

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

This is inspired by some of the recent discussions, in particular the
operator overloading RFC (where the fact that operations on non-overloaded
objects still succeed with just a notice was criticized) and the
increment/decrement RFC, which handles the array case of this proposal for
inc/dec only.


Sounds good!


I think as-is, this RFC should be completely uncontroversial. However,
there is an open question on whether we want to make this slightly more
strict, in order to align the semantics with the rules for weak parameter
type checks for ints/floats.


Regarding that, the RFC says we could “Make non-numeric string operands 
throwing. Non-numeric here means not starting with a digit (optionally 
preceded by whitespace). This would not apply to operators that have 
special behavior for strings, such as string increment.”


I know you used “such as” there, but maybe you should specifically point 
out the bitwise case. I think increment and the bitwise operators are 
the only special cases for strings?



If we do that, then this RFC could be a stepping stone towards making
"implicit" internal casts use the (weak) parameter type checking semantics
more generally, which I think would be a good idea. The current explicit
cast semantics we use everywhere are too forgiving for most circumstances
(e.g. an array is almost always not a reasonable input where an integer is
expected).


That would be nice! We currently have essentially three (actually more 
but these are the big ones) different “weak” behaviours: function 
arguments and return values, non-comparison operators, and comparisons, 
and I doubt people who don't follow internals are fully aware of the 
differences, so it would be good to eventually have just one set of rules.


I guess https://wiki.php.net/rfc/invalid_strings_in_arithmetic was 
already a step in this direction and your RFC is a further development 
of it.


Thanks,
Andrea


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

Re: [PHP-DEV] [RFC] Stricter type-checks for arithmetic/bitwise operators

[G. P. B.]

On Thu, 2 Apr 2020 at 10:14, Nikita Popov  wrote:

> Hi internals,
>
> I would like to propose making the use of arithmetic/bitwise operators on
> arrays, resources and (non-overloaded) objects a TypeError exception:
>
> https://wiki.php.net/rfc/arithmetic_operator_type_checks
>
> This is inspired by some of the recent discussions, in particular the
> operator overloading RFC (where the fact that operations on non-overloaded
> objects still succeed with just a notice was criticized) and the
> increment/decrement RFC, which handles the array case of this proposal for
> inc/dec only.
>
> I think as-is, this RFC should be completely uncontroversial. However,
> there is an open question on whether we want to make this slightly more
> strict, in order to align the semantics with the rules for weak parameter
> type checks for ints/floats.
>

On this topic maybe it would be good time to bring back again the Saner
string to number comparison RFC, at least in some form?
https://wiki.php.net/rfc/string_to_number_comparison

Or is this open question meant to replace it?

And maybe in some other form revive this RFC about allowing trailing
white-spaces in numeric string, because IMHO only accepting those
which have white-spaces in front is kinda weird.


> If we do that, then this RFC could be a stepping stone towards making
> "implicit" internal casts use the (weak) parameter type checking semantics
> more generally, which I think would be a good idea. The current explicit
> cast semantics we use everywhere are too forgiving for most circumstances
> (e.g. an array is almost always not a reasonable input where an integer is
> expected).
>
> Regards,
> Nikita
>

Other than this a solid +1 from me.

George P. Banyard

[PHP-DEV] PHP 7.3.17RC1 is available for testing

[Christoph M. Becker]

PHP 7.3.17RC1 has just been released and can be downloaded from:



Or use the git tag: php-7.3.17RC1

Windows binaries are available at: 

Please test it carefully, and report any bugs in the bug system.
7.3.17 should be expected in 2 weeks, i.e. on April 16th 2020.

Hash values and PGP signatures can be found below or at
.

Thank you, and happy testing!

Regards,
Stanislav Malyshev & Christoph M. Becker


php-7.3.17RC1.tar.bz2
SHA256 hash:
6bb6165b811f94836b796401b5b40df872753cc10bf6746521646c99ab851ea3
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAl6DMZcMHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y2rI0P/Ajd4Sn0IyRh2E6diNhmgVTcldNnMi6JCTGpLcPl
NLkiiyD43ImmoCrw/h4f/qSshHFrT34vFeoXY4OMjdBAiFSTKa5txPwg5JjDThWj
CJS522WtLTGBbXlkUrqgdnnsv9zyge/5xQV4gSZHK0FtwuqNBz/8pidIFf63287H
+D0iJtp1Ki9ob39k+AHH3SWOCePSmu/wHXCVtnsvLHfYCgYrmn18Q/aSo8y7IJPK
SlOtWAvEhEQUlsAGZBsr61yjaNdGsxHon2hp8EX13GQP2II37etpxmJCd4c8pQfs
TTf0FCCS0zcGK6NaELX95tS3dZkijX+pFnGNzDiH5PAmBGx6BcO9nAEpvwjF6g1c
85GMvoyWxSOmKYaej+bePo12dKShrWiz4sLunQ4gtH+eQHLVj8Y1nSgE4L/7hw+d
PeF7Ve2LlAGpPw+TocQGI8SU+OmnDUVMlYot3CvFd/Ne5VgUWV3eLBza/X+J30mL
xuwucH4EUGPlTlqxUCfB2YMexfsLK/5Si54K0DO7lPIng0sM2PDhDg7s7wUq6UA9
owhp7s/TojA7em25MMivgiLmZ5ZKmBoviQga1MTyz9HtMyeHDjFZOQcBcNeQaDb/
Q1zbnNViYDm8vDG7GmotxYdpa6hr2are4Bmhwz1WrCdJS08eNSyXuCA36YzfpuIG
IArF
=R0Pi
-END PGP SIGNATURE-


php-7.3.17RC1.tar.gz
SHA256 hash:
88533d93468233f2a69d90eb03ff848ace7365c9ae869e68b879e54445e80495
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAl6DMZ4MHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y2RWQP/1m1ilADUOLIyNpJBfcGglDRSbn2jc5uof8hGXfB
WxtfWu6ftD37fxkVwVVloEKiSldfTfdt4zMKeD+QhkSAJPYHx0WViR2bkgKZb6tS
OTIA5JPjFN63mjpy2BmlaZlmMJIsiLCzGSaQk9LkkyBy7k8RpsBhaeeTPhlQyK9e
k0MXtHn0AkP5ywu8n16t+j1sSw654IdDcpm4naSko9y1GZ1LBNjEko8UgR2tklhd
2Il0+n2zLSgMRzap1La9Y2F9umsepkz7tzO02K4g5zPFrhPsBzQY0VEqMRKK7hnA
imu/iVyYQupvl4BeWEB0wvODIgE8bpvZKrH8m3Vsq/0fCqHV090xI7mYOmLIXclD
MvAD2/B8aZgd3xD3dHSQi384RVko7b59jcpsEX7gZLtf7scEz2eFZJYzIgdPwXPm
M/63rk0kRUAv4tL88mpscPfilRDkFuPDdBhVZUj2/Wo6EG0V57O4I6eH3e+xt8J4
CfQXAEzjN9UG1+9NrEU6VtxwAAadRbFLXXxN+SQIoHLukRm4ypqVpftgW87Lde75
AkNHXDmfydJEWRen/rM3H8vpUD2rpJiZ2Jw7rzZ7sq0xErwDb8z59sisaoNzFMxy
0FnP3beQiKX0q65qMGUJJppUbXRwx3peBdMkffHmLEaXJ3SLfIXQi9bOeKhvastv
lJCp
=Tzm3
-END PGP SIGNATURE-


php-7.3.17RC1.tar.xz
SHA256 hash:
73b981de2c89234381eb9d65374900d2cdc80701ab6aab92a5c5ed61c1d998d4
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAl6DMZ4MHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y2cO8P/3arQ8929S/EGNIgBDE7Dp14JSVIWyXuPqxzDwCK
E57DUrtxPD3RB0zxq7UFabtz0HvZkMoZwokDmOFc80ujUMfv2X0Q/qg53Cmhka2e
9fqkjP2krfNReqG4R6DzodoJHtST+PBTmt/x/PqzaS++O+hN0g+KrReTWu6SjPwd
pW76xUNI2KObl3euG0A3Hmk0hW+KUxJgiFXkOltgxGXH3XItdmWXKMvRJvyISs2N
KEUIgO3qURCD82bMbIX61BgkHrqx5csstFj8EBv6lDPqxt2bYiAS6FsWLsOfDvER
2NnS9YTutxgb2T9tdg6VeS4qpn+iWjnMnA67Ncj4spIUPSzEzF6nzmwikWdkdPCE
6WpFubo18oxGbd7KKpOyQRHs1cArIE3F1pFhPtauk5eDk4e3/Hgqm6o3H0FWTXKY
7gBT4A2deDDpL1AiDS5EBJBWLy3tBu0tWXnGonZeTWtG4ws2O3qVchw1uHOrmLnb
m0NWt0fs3hR6EOXUW6ZFU/Md+6eTbMOPudfpcN2vIAspP6dC3WB0BChH46Nzvj4Y
Ap8GmoQGcpWyzy5kpvQ1jwX2+H3jdvgLbvpDC2ePfMNe5Rd0BzFltTVPosUAzbcH
qryGFMCAsJuvwjqCGaAGu3EBRM6EYLbagB8tdfIrG2sXv5lksHdTTuGhaK2tre/L
Ierm
=MWZl
-END PGP SIGNATURE-

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

Re: [PHP-DEV] [VOTE] Userspace operator overloading

[Nikita Popov]

On Sat, Mar 28, 2020 at 10:19 PM Andrea Faulds  wrote:

> Hi everyone,
>
> Johannes Schlüter wrote:
> >
> > If we use two methods as well it is a saner design. I won't like it, but
> lot better than the current one.
>
> Just want to +1 this. Two methods, neither of which are static, seems
> like a cleaner approach to me. I maybe like this better than my
> suggested boolean argument (it certainly looks nicer).
>
> Consider what happens in the current proposal if a class, intentionally
> or otherwise, only supports being on one side of an operator… it will
> produce the same error message as if it didn't support the overload at
> all :(


Could you please expand on what the advantage of using two instance methods
over one static method is? As far as I can tell, Python uses this design
because they don't really have static methods (let's gloss over the
@staticmethod decorator here), so it's basically their only choice.

I don't buy your error message argument. Assuming
https://wiki.php.net/rfc/arithmetic_operator_type_checks passes, the error
you're going to get is something like "Unsupported operand types: int /
Vector", which seems reasonable to me, and leaves potential support for
"Vector / int" open.

The presence of only one of the two method could not be used for the error
message anyway, because presence of the method does not imply actual
support of the type combination, and we certainly wouldn't want to do a
call for the reverse order to adjust the error message.

Regards,
Nikita

Re: [PHP-DEV] [RFC] Constructor Property Promotion

[Nikita Popov]

On Thu, Apr 2, 2020 at 1:35 AM Markus Fischer  wrote:

> Hi,
> On 2020-03-26 14:30, Nikita Popov wrote:
> > I would like to submit the following RFC for your consideration:
> > https://wiki.php.net/rfc/constructor_promotion
> >
> > This is based on one off the suggestions made in
> > https://externals.io/message/109220, and some existing discussion on the
> > topic can be found in that thread.
> >
> > The primary motivation for this feature is to close the currently rather
> > wide gap between the use of ad-hoc array structures, and the use of
> > well-defined and type-safe value objects. The latter is what we want
> people
> > to use, but the former is, unfortunately, what is *easy* to use.
>
> The amount of boilerplate this would cut down for e.g. projects using DI
> and DTOs is unfathomable.
>
> How does this work together with reflection? Will reflection see the
> properties _and_ the extended constructor definitions?
>

Reflection will see the state after desugaring. That is, it just sees
normal properties and normal constructor args. I've made this more explicit
in the RFC now: https://wiki.php.net/rfc/constructor_promotion#reflection

Nikita

[PHP-DEV] Re: [RFC] Stricter type-checks for arithmetic/bitwise operators

[Christoph M. Becker]

On 02.04.2020 at 10:47, Nikita Popov wrote:

> On Thu, Apr 2, 2020 at 10:35 AM Christoph M. Becker 
> wrote:
>
>> On 02.04.2020 at 10:14, Nikita Popov wrote:
>>
>>> I would like to propose making the use of arithmetic/bitwise operators on
>>> arrays, resources and (non-overloaded) objects a TypeError exception:
>>>
>>> https://wiki.php.net/rfc/arithmetic_operator_type_checks
>>
>> Thanks!  Generally I like that very much.  I'm not quite sure, though,
>> what to do with resource to int conversions.  These are documented to be
>> valid[1], and are sometimes deliberately used[2], and as such it might
>> be reasonable not to throw on these conversions (maybe even change the
>> current behavior of the ~ operator).
>
> While resource to int conversions are indeed valid, they are not exactly
> commonly used, and if they are used, I would expect an explicit (int) cast
> to be involved. I very seriously doubt that someone writing "$x = $y / 2"
> really intended this to mean "$x = resource_id($y) / 2" -- it is much more
> likely that a variable go mixed up. In the unlikely case that that they
> really did intend that, the option of writing "$resourceId = (int) $y; $x =
> $resourceId / 2" remains, and is much clearer.
>
> On that note, I do wonder whether we should introduce a function like
> get_resource_id(), that makes it more explicit that an (int) cast is
> supposed to fetch a resource ID. This is not a very common operation, and I
> suspect that many PHP programmers may not be familiar with the semantics of
> integer casts on resources. Using get_resource_id($file) would make the
> intent clearer relative to (int) $file. This is similar to the recently
> added get_mangled_object_vars() function, which essentially does the same
> as (array) $object, but makes it obvious that you really are interested in
> mangled properties.

I think something like get_resource_id() would be a good addition.

>> After all, I hope we will be able
>> to port all resources to objects sometime, and till then we could stick
>> with more lax semantics.
>
> I think that's really an argument to align the behavior of resources and
> objects, as it means one less BC break when resources are converted to
> objects. Historically that's something we did in minor versions, so it's
> good to reduce the amount of semantics that change when such a conversion
> is done.

Good point indeed!

So +1 from me on the RFC.  Not absolutely sure about the open questing
regarding going one step further, but tentatively also +1 on that.

Thanks,
Christoph

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

[PHP-DEV] Re: [RFC] Stricter type-checks for arithmetic/bitwise operators

[Nikita Popov]

On Thu, Apr 2, 2020 at 10:35 AM Christoph M. Becker 
wrote:

> On 02.04.2020 at 10:14, Nikita Popov wrote:
>
> > I would like to propose making the use of arithmetic/bitwise operators on
> > arrays, resources and (non-overloaded) objects a TypeError exception:
> >
> > https://wiki.php.net/rfc/arithmetic_operator_type_checks
> >
> > This is inspired by some of the recent discussions, in particular the
> > operator overloading RFC (where the fact that operations on
> non-overloaded
> > objects still succeed with just a notice was criticized) and the
> > increment/decrement RFC, which handles the array case of this proposal
> for
> > inc/dec only.
> >
> > I think as-is, this RFC should be completely uncontroversial. However,
> > there is an open question on whether we want to make this slightly more
> > strict, in order to align the semantics with the rules for weak parameter
> > type checks for ints/floats.
> >
> > If we do that, then this RFC could be a stepping stone towards making
> > "implicit" internal casts use the (weak) parameter type checking
> semantics
> > more generally, which I think would be a good idea. The current explicit
> > cast semantics we use everywhere are too forgiving for most circumstances
> > (e.g. an array is almost always not a reasonable input where an integer
> is
> > expected).
>
> Thanks!  Generally I like that very much.  I'm not quite sure, though,
> what to do with resource to int conversions.  These are documented to be
> valid[1], and are sometimes deliberately used[2], and as such it might
> be reasonable not to throw on these conversions (maybe even change the
> current behavior of the ~ operator).
>

While resource to int conversions are indeed valid, they are not exactly
commonly used, and if they are used, I would expect an explicit (int) cast
to be involved. I very seriously doubt that someone writing "$x = $y / 2"
really intended this to mean "$x = resource_id($y) / 2" -- it is much more
likely that a variable go mixed up. In the unlikely case that that they
really did intend that, the option of writing "$resourceId = (int) $y; $x =
$resourceId / 2" remains, and is much clearer.

On that note, I do wonder whether we should introduce a function like
get_resource_id(), that makes it more explicit that an (int) cast is
supposed to fetch a resource ID. This is not a very common operation, and I
suspect that many PHP programmers may not be familiar with the semantics of
integer casts on resources. Using get_resource_id($file) would make the
intent clearer relative to (int) $file. This is similar to the recently
added get_mangled_object_vars() function, which essentially does the same
as (array) $object, but makes it obvious that you really are interested in
mangled properties.

> After all, I hope we will be able
> to port all resources to objects sometime, and till then we could stick
> with more lax semantics.

I think that's really an argument to align the behavior of resources and
objects, as it means one less BC break when resources are converted to
objects. Historically that's something we did in minor versions, so it's
good to reduce the amount of semantics that change when such a conversion
is done.

Regards,
Nikita

[PHP-DEV] Re: [RFC] Stricter type-checks for arithmetic/bitwise operators

[Christoph M. Becker]

On 02.04.2020 at 10:14, Nikita Popov wrote:

> I would like to propose making the use of arithmetic/bitwise operators on
> arrays, resources and (non-overloaded) objects a TypeError exception:
>
> https://wiki.php.net/rfc/arithmetic_operator_type_checks
>
> This is inspired by some of the recent discussions, in particular the
> operator overloading RFC (where the fact that operations on non-overloaded
> objects still succeed with just a notice was criticized) and the
> increment/decrement RFC, which handles the array case of this proposal for
> inc/dec only.
>
> I think as-is, this RFC should be completely uncontroversial. However,
> there is an open question on whether we want to make this slightly more
> strict, in order to align the semantics with the rules for weak parameter
> type checks for ints/floats.
>
> If we do that, then this RFC could be a stepping stone towards making
> "implicit" internal casts use the (weak) parameter type checking semantics
> more generally, which I think would be a good idea. The current explicit
> cast semantics we use everywhere are too forgiving for most circumstances
> (e.g. an array is almost always not a reasonable input where an integer is
> expected).

Thanks!  Generally I like that very much.  I'm not quite sure, though,
what to do with resource to int conversions.  These are documented to be
valid[1], and are sometimes deliberately used[2], and as such it might
be reasonable not to throw on these conversions (maybe even change the
current behavior of the ~ operator).  After all, I hope we will be able
to port all resources to objects sometime, and till then we could stick
with more lax semantics.

[1] 
[2]


--
Christoph M. Becker

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

[PHP-DEV] [RFC] Stricter type-checks for arithmetic/bitwise operators

[Nikita Popov]

Hi internals,

I would like to propose making the use of arithmetic/bitwise operators on
arrays, resources and (non-overloaded) objects a TypeError exception:

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

This is inspired by some of the recent discussions, in particular the
operator overloading RFC (where the fact that operations on non-overloaded
objects still succeed with just a notice was criticized) and the
increment/decrement RFC, which handles the array case of this proposal for
inc/dec only.

I think as-is, this RFC should be completely uncontroversial. However,
there is an open question on whether we want to make this slightly more
strict, in order to align the semantics with the rules for weak parameter
type checks for ints/floats.

If we do that, then this RFC could be a stepping stone towards making
"implicit" internal casts use the (weak) parameter type checking semantics
more generally, which I think would be a good idea. The current explicit
cast semantics we use everywhere are too forgiving for most circumstances
(e.g. an array is almost always not a reasonable input where an integer is
expected).

Regards,
Nikita