Re: [PHP-DEV] [VOTE] Type casting in array destructuring expressions

[Enno Woortmann]

Am 09.04.2020 um 11:41 schrieb Enno Woortmann:

Hi together,

I have opened the voting for adding type casting in array destructuring
expressions:

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

As the future scopes section of this proposal includes additional
possible topics (eg. strict casts or the alternative solution via
regular type checks in array destructuring expressions) I've included an
additional poll to see which of these topics may be tackled in the near
future.

Voting closes on April 23th.

Thanks for everyone participating in the vote.

Cheers, Enno



Hi,

the voting has been closed. The RFC is declined with 6 votes in favour
and 26 votes against adding type casting in array destructuring expressions.

Cheers, Enno

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

Re: [PHP-DEV] Type hints in array destructuring expressions

[Enno Woortmann]

Am 16.04.2020 um 16:50 schrieb Nikita Popov:

As you say, this syntax will likely run into parsing issues. Once you take
into account that types aren't just "int", but also "Foo|Bar", and also
consider that we have support for references in unpacking, you could be
left with something like

 [int|float &$foo] = $bar;

Without actually testing, I would expect that this is going to run into
issues of similar difficulty as the arrow function proposal encountered.

Rather than integrating this into the destructuring assignment syntax, I
think it would be more helpful to view this as the infallible variant of
pattern matching, which is also being discussed in the "match expression"
thread. As suggested there, the syntax could be something like

 let [int|float $foo] = $bar;

and would throw if the RHS does not satisfy the pattern on the LHS (unlike
the match variant, which is fallible).

I think this might help to bring things under one umbrella, and to draw a
clearer line between this functionality and typed variables (if it's just a
pattern guard, then it's expected that the type restriction is checked
instantaneous, not enforced persistently.)

Nikita


Hi Nikita,

thanks for your response and your assessment concerning the parser change.

I've played a bit around with the idea and came to the conclusion that
changes like these are far beyond my knowledge of the code base and my C
skills. Consequently I will not continue working on this idea as it
moves away from my initial idea to simply cast values.

If anyone wants to take this RFC draft, feel free to tackle this topic
further. The secondary voting of the "casting in array destructuring
expressions RFC" which will be closed in two days shows some interest
into this topic.

Cheers, Enno

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

Re: [PHP-DEV] Type hints in array destructuring expressions

[Enno Woortmann]

Hi,


- It has been requested several times on this list to stop using the
wording "type hint" and instead write "type declaration" ;)



I've updated the RFC to use the "type declaration" wording, thanks for
the hint :)



- When I see this example in the RFC:
```
$years = [["now", 2020], ["future", 2021]];
foreach ($years as [string $description, int $year]) {
```
I immediately think of a similar:
```
$years = ["now" => 2020, "future" => 2021];
foreach ($years as string $description => int $year) {
```
or:
```
$foos = [new Foo("one"), new Foo("two")];
foreach ($foos as Foo $foo) {
```



As the RFC tackles array destructuring expressions and not foreach loops
(which is just an option to use array destructuring there) I think this
is out of scope for the RFC. I've added it to the future scope section
though as I think it would align with the current proposal.

Thanks for the input!

Cheers, Enno

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

Re: [PHP-DEV] Type hints in array destructuring expressions

[Enno Woortmann]

Agree this would slow things down but if it could be potentially type
checked on the assignment with type constraint in front of the variable
name I think that would be a neat feature.
So to work as a function parameter but not like a typed property.


Hi Michał,

A type check during the assignment is the intent of the proposal. I'll
update the description to state this more explicit.

As i wrote in the initial mail the implementation side is the one which
is currently mostly unclear to me. To see which parts of the language
would be affected by the change. I think if it's implemented in a
central way each assignment could be affected by a type check. But as
Nicolas stated that should be kept in a separate RFC if that's something
we want to tackle further.

Cheers, Enno

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

[PHP-DEV] Type hints in array destructuring expressions

[Enno Woortmann]

Hi together,

as the voting for the "Type casting in array destructuring expressions"
shows a clear direction to be declined (sad faces on my side, I really
would've liked it as a feature completion of the casting feature set
without the need for a really new syntax, as the parser also already
coverred it, but ok, time to continue :D ), combined with a strong
interest for the topic "type checks in array destructuring expressions"
(as well in the discussion as in the vote) I've set up a first draft of
an RFC covering this topic:

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

The discussion around the casting in array destructuring brought up the
idea to perform regular type checks in array destructuring expressions.
This RFC proposes a new syntax to type hint a variable inside an array
destructuring expression:

$data = [42, 'Example', 2002];
[int $id, string $data, int $year] = $data;

The type hints behave identically to the type hints used in method
signatures (compare https://wiki.php.net/rfc/scalar_type_hints_v5). This
especially includes a behaviour depending on the strict_types directive.

Additionally to scalar type hints also object type hints are possible.

I've not yet started an implementation draft but I think this one will
be more tricky than the type cast implementation approach. As the parser
re-uses the array definition for array destructuring expressions (which
also leads to the type cast implementation without touching the parser)
adding type hints to the definition would also affect other parts of the
language eg. something like:

$x = [int $a, string $b];

would be parsed by the parser. I'm currently not able to grasp the
impact of such a change. But that's another topic.

Let's focus on the idea itself instead of the implementation first.
Thoughts on the first draft?

Cheers, Enno

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

[PHP-DEV] [VOTE] Type casting in array destructuring expressions

[Enno Woortmann]

Hi together,

I have opened the voting for adding type casting in array destructuring
expressions:

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

As the future scopes section of this proposal includes additional
possible topics (eg. strict casts or the alternative solution via
regular type checks in array destructuring expressions) I've included an
additional poll to see which of these topics may be tackled in the near
future.

Voting closes on April 23th.

Thanks for everyone participating in the vote.

Cheers, Enno

Re: [PHP-DEV] [RFC] [DISCUSSION] Type casting in array destructuring expressions

[Enno Woortmann]

Am 07.04.2020 um 19:24 schrieb Claude Pache:



Le 7 avr. 2020 à 17:09, Enno Woortmann  a écrit :

As the proposal explicitly aims at type casts
when working with data from a untyped source (eg. iterating over a CSV
file, XML without a XSD defining the types of the elements)

I feel that the RFC lacks a section named “Motivation”...

That said, the larger question is: How many ad-hoc features do we want to add 
to array destructuring? For type-casting is one specific kind of transformation 
you may want to apply to your data.

—Claude



I've added a motivation section to the RFC describing the target of the
proposal, added a discussion section describing the difference between
the proposal and type checks while array destructuring and extended the
patch section to include a description of the change.

Enno

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

Re: [PHP-DEV] [RFC] [DISCUSSION] Type casting in array destructuring expressions

[Enno Woortmann]

Am 07.04.2020 um 13:14 schrieb Nicolas Grekas:

Le mar. 7 avr. 2020 à 12:07, Enno Woortmann  a
écrit :


Am 25.03.2020 um 18:53 schrieb Enno Woortmann:


Hi,

I've written the RFC and implemented a first patch concerning the idea
to allow type casting in array destructuring expressions.


The RFC is located at
https://wiki.php.net/rfc/typecast_array_desctructuring

The patch can be found in MR 5296 located at
https://github.com/php/php-src/pull/5296


Thanks for further feedback!

Cheers, Enno


Hi together,

As there has been no recent discussion concerning this RFC (tbh no
discussion at all, I don't know if it's like "ok, cool idea, just let's
do it" or more like "oh no, let's forget this asap") I'd like to start
the voting tomorrow if there are no further comments on this proposal.



On my side, I like the idea but the proposed syntax looks weird.
I would vastly prefer (and upvote) Levi's proposal:

[int $a] = [123]; // note: no brackets, this is a type declaration, not a
casting operation
[string $a] = [123]; // TypeError or implicit cast depending on
declare(strict_types=1/0) in the file

Nicolas



Hi Nicolas,

thanks for your comment. As the proposal explicitly aims at type casts
when working with data from a untyped source (eg. iterating over a CSV
file, XML without a XSD defining the types of the elements) an
implementation following the type check proposal would force me to write
my code into a file with  strict_types=0. As I'm a big fan of
strict_types=1, I try to avoid such files (fingers crossed for the
namespace scoped declares some day, but then I'd need to move my code to
a separate namespace), also see my answer to Rowan @
https://externals.io/message/109305#109354 with different combinations.

Maybe, as the type system get's a many improvements lately (eg. typed
properties), it's also time to think about a refined type cast system
for better control over the casting process (nullable casts already have
been a topic, additionally strict casts as suggested by Rowan).

I also like Levi's proposal but for the use cases which lead me to the
idea for this proposal where I explicitly want to cast values and don't
check their current types it's difficult to use. I think it serves
different use cases.

You mention the syntax looks weird to you. How would you design the
syntax if you want to cast the values instead of type checking them?

Cheers Enno

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

Re: [PHP-DEV] [RFC] [DISCUSSION] Type casting in array destructuring expressions

[Enno Woortmann]

Am 25.03.2020 um 18:53 schrieb Enno Woortmann:


Hi,

I've written the RFC and implemented a first patch concerning the idea
to allow type casting in array destructuring expressions.


The RFC is located at
https://wiki.php.net/rfc/typecast_array_desctructuring

The patch can be found in MR 5296 located at
https://github.com/php/php-src/pull/5296


Thanks for further feedback!

Cheers, Enno



Hi together,

As there has been no recent discussion concerning this RFC (tbh no
discussion at all, I don't know if it's like "ok, cool idea, just let's
do it" or more like "oh no, let's forget this asap") I'd like to start
the voting tomorrow if there are no further comments on this proposal.

Cheers, Enno

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

Re: [PHP-DEV] Feature request - allow to append multiple elements to an array

[Enno Woortmann]

Hi Michael,

why not simply use array_push with multiple arguments? Something like:

$a = [];
array_push($a, ...array_fill(0, 10, 'x'));
echo print_r($a, true);

Cheers, Enno

Am 29.03.2020 um 00:07 schrieb Michael Voříšek - ČVUT FEL:

Hi all PHP gurus!
This is a feature request / RFC for the following use-case:
$res = [];
foreach ($arr as $i) {
foreach (make_res($i) as $v) {
$res[] = $v;
}
}
Array_merge in loop is very sloop so it is not a solution.
which I propose to shorten to:
$res = [];
foreach ($arr as $i) {
$res[...] = make_res($i);
}
Appending multiple elements to an array is very common use-case.
With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,

Michael Voříšek


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

Re: [PHP-DEV] [RFC] [DISCUSSION] Type casting in array destructuring expressions

[Enno Woortmann]

$handle = fopen('test.csv', 'r');
while (($data = fgetcsv($handle)) !== false) {
  [int $id, string $data, int $year] = $data;
  // do something with the correctly typed variables
}

The code would trigger a fatal error when strict_types are enabled. With
strict_types disabled it would behave identically as the currently
proposed casts.



As I mentioned in a previous e-mail, if it followed current strict_types=0
semantics, it would error if the input row was something like
"42,hello,not-a-valid-year".

Following standard cast semantics, that input would instead silently give
you a value of 0 in $year, which is often not what you want.



Hi Rowan,

I liked your idea of strict casts which would increase the possibilities
of casting in general but also improve casting while array destructuring.

Let's have a look at various combinations.

The current proposal (behaviour doesn't depend on strict_types):

[(int) $id, (string) $data, (int) $year] = $data;

"42,hello,2020" --> Works as expected, everything fine
"42,hello,not-a-valid-year" --> results silently in a 0. May not be
wanted, as you describe, but in my opinion that's fine as it's the
current casting behaviour


Extending the proposal with strict castings (behaviour doesn't depend on
strict_types):

[(!int) $id, (!string) $data, (!int) $year] = $data;

"42,hello,2020" --> Works as expected, everything fine as "2020" can be
casted to an int
"42,hello,not-a-valid-year" --> Results in a TypeError as the year can't
be casted to an int


Using regular type checks (depends on strict_typed):

declare(strict_types=0);
[int $id, string $data, int $year] = $data;

"42,hello,2020" --> Works as expected, everything fine as the id with
"42" and the year with "2020" can be casted to an int
"42,hello,not-a-valid-year" --> Results in a TypeError as the year can't
be casted to an int


declare(strict_types=1);
[int $id, string $data, int $year] = $data;

"42,hello,2020" --> Results in a TypeError as id and year are both strings
"42,hello,not-a-valid-year" --> Results in a TypeError as id and year
are both strings

My favourite behaviour would be the one described for strict
castings/regular type checks with strict_types disabled. But I don't
like the idea it's only usable without strict_types to get the
casting-feature intended by the RFC.

Cheers, Enno

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

Re: [PHP-DEV] [RFC] [DISCUSSION] Type casting in array destructuring expressions

[Enno Woortmann]

Hi Levi,

Am 25.03.2020 um 21:44 schrieb Levi Morrison:

To me, this is almost a good idea. However, I would want regular type
checking, not casts. Importantly, regular type checks would fit well
on allowing array destructuring directly in function signatures, which
would basically be a form of named parameters.



How exactly do you imagine array destructuring in function signatures
with type checks? Something like:

function test(['parameter1' => int $parameter1, 'parameter2' => string
$parameter2) {
    // ... do something with $parameter1 and $parameter2
}

Calling the function then may look like:

test(['parameter1' => 100, 'parameter2' => 'Hello World']);

I guess the type check then depends on the strict_types direcitve
whether a call like:

test(['parameter1' => 100, 'parameter2' => 100]);

would trigger a TypeError or be valid and cast the value for $parameter2
to a string just like a casual function signature with a string parameter.


The same behaviour would be applied to array destructuring outside of
function signatures. Assumed we gather data from a CSV file:

1,Test,2002
2,Example,2010
3,Demo,2016

And we want to process the data with array destructuring like:

$handle = fopen('test.csv', 'r');
while (($data = fgetcsv($handle)) !== false) {
    [int $id, string $data, int $year] = $data;
    // do something with the correctly typed variables
}

The code would trigger a fatal error when strict_types are enabled. With
strict_types disabled it would behave identically as the currently
proposed casts. I wouldn't want the example above to trigger a TypeError
even when strict_types are enabled. As a form of named parameters
regular type checks should definitely preferred over a cast but for the
current usage of array destructuring I think regular type checks cover
different use cases (which may also exist) than my proposal.

Enno

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

[PHP-DEV] [RFC] [DISCUSSION] Type casting in array destructuring expressions

[Enno Woortmann]

Hi,

I've written the RFC and implemented a first patch concerning the idea
to allow type casting in array destructuring expressions.


The RFC is located at https://wiki.php.net/rfc/typecast_array_desctructuring

The patch can be found in MR 5296 located at
https://github.com/php/php-src/pull/5296


Thanks for further feedback!

Cheers, Enno

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

[PHP-DEV] Type casting while array destructuring

[Enno Woortmann]

Hi,

currently when using array destructuring the variables are assigned as
they are. For example we split a string with explode all variables will
contain strings:

$data = "foo:*:1023:1000::/home/foo:/bin/sh";
[$user, $pass, $uid, $gid, $gecos, $home, $shell] = explode(":", $data);

If we want to write functions consuming $uid and $gid as integer values
with strict types enabled we need to cast the values afterwards:

$uid = (int) $uid;
$gid = (int) $gid;
// or during the function call
$myConsumingObject->myConsumingFunction((int) $uid, (int) $gid);

I think you get my point. How about adding some syntactic sugar and
allow type casting inside the detructuring expression?

$data = "foo:*:1023:1000::/home/foo:/bin/sh";
[$user, $pass, (int) $uid, (int) $gid, $gecos, $home, $shell] =
explode(":", $data);
// $uid and $gid are integer values now. All other variables remain as
they are and contain strings

An example with associative arrays in loops:

$array = [
    [
    'name' => 'a',
    'id' => '1'
    ],
    [
    'name' => 'b',
    'id' => '2'
    ],
];

foreach ($array as ['id' => (int) $id, 'name' => $name]) {
    // $id contains integer values
}

Further thoughts: when using the list() reference assignment implemented
in PHP7.3 the referenced value could be casted (something to discuss
about, maybe as future scope as casting a reference assignment currently
isn't supported):

$array = [1, 2];
[(string) $a, (string) &$b] = $array;
// $a would be a string: '1'
// $b would be a string: '2'
// $array would contain one integer and one string element: [1, '2']

Thoughts?

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

Re: [PHP-DEV] Replacing array_slice

[Enno Woortmann]

Am 17.07.2018 um 07:35 schrieb Zeev Suraski:

On 17 Jul 2018, at 7:12, Levi Morrison  wrote:

Fixing `array_slice` would probably do more harm than good at this
stage. Instead I would like to provide an alternative function that
does not have all this baggage, and will have decent performance much
of the time. The best ideas I have for names are not that great:

  - `array_real_slice`?
  - `array_slice2`?

array_carve()?  array_chisel()?

Zeev



If keeping it together in a single function maybe array_extract() will 
do the job.
Or do you think it's to close to the naming of extract() and may lead to 
confusion?


Enno

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

Re: [PHP-DEV] [VOTE] array_key_first(), array_key_last(), array_value_first(), array_value_last()

[Enno Woortmann]

Am 09.07.2018 um 13:16 schrieb Woortmann, Enno:


Hi,

as the discussion got no new contributions I'd like to start the 
voting for the RFC fo add new functions for the handling of outer 
array elements.


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

To have a better separation I split up the vote for the functions. The 
first vote covers the functions to handle keys: array_key_first() and 
array_key_last(). The second vote covers the corresponding functions 
to handle the values: array_value_first() and array_value_last().


As this RFC adds functions but doesn't change the language syntax a 
50% + 1 majority is required for both votes. The votes are open until 
2018-07-16.


The discussion for this RFC is located at

https://externals.io/message/102245

Regards,

Enno


Hello together,

The vote for this RFC has been closed. The vote for the initially RFC 
containing the functions array_key_first() and array_key_last() was 
accepted, the vote for the extended RFC (adding also array_value_first() 
and array_value_last()) was declined.


I'll update the pull request located at 
https://github.com/php/php-src/pull/3256 tomorrow and remove the 
array_value functions as well as adopt the code review remarks of 
derickr so the PR can be merged for PHP 7.3.


Thanks for the participation,
Enno



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

Re: [PHP-DEV] Re:[PHP-DEV] [VOTE] array_key_first(),array_key_last(), array_value_first(),array_value_last()

[Enno Woortmann]

Am 11.07.2018 um 20:18 schrieb Levi Morrison:


In my opinion neither rejecting the RFC nor changing it to return tuples
solves the underlying problem.

What is the underlying problem in your opinion?

My opinion is that the core problem is that these functions cannot be
efficiently implemented in userland, at least not the ones that get
the last key and/or value of the array. You either need to make a copy
or traverse through the whole array.


With the problem I didn't aim at the problem this RFC tries to solve. I 
think everyone participating in the discussions in the mailing list 
understood the problem of non efficient userland implementations.


I aimed at the issue which lead to the gap between our implementation 
approaches: the indistinguishability between a correct function call 
which returns null and an invalid call with either an empty array or a 
non array value.
As this is an existing problem I still think we should find a common 
solution (which can't be part of this RFC's scope) instead of bringing 
up new function signature patterns for new functions.



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

Re: [PHP-DEV] [RFC][Under Discussion] Add functions array_key_first()and array_key_last()

[Enno Woortmann]

Am 28.06.2018 um 16:52 schrieb Levi Morrison:

I think there has been a lack of discussion about why this is desired.
For me, it's always been implementing certain kinds of iterators that
wrap arrays. This means that functions which return both the key and
value are optimal for me. As I already outlined the functions which
return the key-value pair are the most general and do result in clean
code without drawbacks, at least for this use-case.

Some people do not like this idea. One potential implication this that
maybe their use-case is not the same as mine. What use-cases do other
people have for this? Why are you wanting to grab the first or last
value? What data structure or algorithm is this a bigger part of?

Hi Levi,

sorry for the long-lasting answer.

I use plain arrays relatively often when I develop caching mechanics for 
multiple rather complex entities. I query a set of suitable entites and 
store them as a plain array eg. in Redis.
Each request now fetches this preprocessed entities. Sometimes all 
entities are required but I also have use cases where I filter/sort the 
list of entries and only one entity is interesting (in all cases I 
experienced either the first or the last element). This is my initial 
use case for this RFC.


Are there other opinions about the necessity of this functions?

Regards,
Enno



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

Re: [PHP-DEV] [RFC][Under Discussion] Add functions array_key_first() and array_key_last()

[Enno Woortmann]

Hi niel,

Am 18.06.2018 um 01:59 schrieb niel:
However my main concern that a non-array variable or a non-existent 
value, are an error and need to be handled appropriately, has not 
changed. IMO, a notice/warning does little to nothing in helping the 
programmer determine the problem and track down the cause. Which 
leaves one having to wrap these functions in 'if (is_array($var) && 
!empty($var)) {...}' to prevent the possibility.


The current implementation is eqivalent to the other array_* functions 
as shown in the previous mail and can be checked in

https://github.com/php/php-src/pull/3256/commits/ec2332be93272d202a2a5cef841c266f77f64b08#diff-e00a584724b997f38e851e15f1e20c39

I can comprehend your doubts about the return value but currently I 
can't imagine a solution which would suite the case better than null 
especially if we think about extending the scope to 
array_value_(first|last).
Do you/anyone have an idea how we can provide better information towards 
the programmer to determine the issue?


Enno


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

Re: [PHP-DEV] xmlrpc extension maintainership?

[Enno Woortmann]

Am 17.06.2018 um 22:59 schrieb Stanislav Malyshev:

Hi!

About 2 years ago, in https://externals.io/message/94540#94546, you
expressed interest in maintaining XML-RPC extension. I haven't seen any
activity from you since then. Are you still interested? If so, it might
be a good idea to look through XMLRPC bugs:
https://bugs.php.net/search.php?cmd=display_type=All=Open_name%5B%5D=XMLRPC-EPI+related=Any=30
and see if you could help with any of those, submit patches and then
request developer account (http://php.net/git-php.php).
Please notify us if you're still interested.

Thanks,


Hi Stas,

is there a list available with unmaintained extensions which are still 
inside the core?


Regards,
Enno

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

Re: [PHP-DEV] [RFC][Under Discussion] Add functions array_key_first() and array_key_last()

[Enno Woortmann]

Hi Alice,


Am 17.06.2018 um 22:16 schrieb Alice Wonder:
boolean is a value, null is the absence of a value, which is more 
accurate, no?


In my opinion that's the argument to return null for either parameters 
which aren't an array or empty arrays simply because a first/last key 
isn't present and null is the value to be returned for an undefined state.
I've tested this behavior with other array_* functions which are 
provided in the PHP core and they provide null consistently, eg.:


root@WOL-Soft-DEVVM:/var/www/WOL-Soft# php -r "var_dump(array_keys(1));"
PHP Warning:  array_keys() expects parameter 1 to be array, integer 
given in Command line code on line 1

NULL
root@WOL-Soft-DEVVM:/var/www/WOL-Soft# php -r 
"var_dump(array_values('hello'));"
PHP Warning:  array_values() expects parameter 1 to be array, string 
given in Command line code on line 1

NULL
root@WOL-Soft-DEVVM:/var/www/WOL-Soft# php -r "var_dump(array_flip(null));"
PHP Warning:  array_flip() expects parameter 1 to be array, null given 
in Command line code on line 1

NULL

There was another remark which wasn't sent to the internals mail list 
but to my personal mail account (mehh :( ) which supported to return false:


"because a lot of functions act the way returning false when things go
wrong even when they normally only would return string/int/array which
should be justification enough: consistency"

An example for this argument was the function strpos which may be 
checked with === or !== against false.
But the real discussion about the return value and the facility of 
comparison against another value is only interesting if we extend the 
scope of this RFC to cover also array_value_(first|last), as null as an 
array key is not supported and will be casted to an empty string. Due to 
this internal handling of array keys, null is for the functions 
array_key(first|last) an unique return value to evaluate failures.


My opinion about this subject supports your argument as null is the 
value which should be returned if the requested value is not defined. If 
a variable which is neither an array nor an array with entries is passed 
neither the first/last key nor the first/last value is a defined value 
and thus null should be the return value.


Especially if we decide to extend the scope of this RFC to cover also 
array_value_(first|last) there is no possibility to provide a return 
value which doesn't collide with a possible array value. If cases occur 
which may resolve into a collision, the usage of functions like 
is_array() and empty()/count() is inevitable as both null and false are 
valid values for an array value. To argument with the semantic of false 
and null the correct return value should be null for each of the 
proposed functions (as well the proposed functions which are currently 
covered by the RFC as the extended version which also covers the methody 
array_value(first|last) ) as null defines an undefined value.


Regards,
Enno


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

Re: [PHP-DEV] [RFC][Under Discussion] Add functions array_key_first() and array_key_last()

[Enno Woortmann]

Hi niel,


On 15.06.2018 at 17:37 niel wrote:
What is the behaviour if the array does not exist? From the current 
RFC it appears it would return null? Wouldn't it be better to return 
false for this situation?




Thanks for the comment. Why do you think false would be a better return 
value?


Currently if the given value isn't an array or no parameter is given a 
warning will be thrown and null will be returned.
In my opinion null exists to show the absence of a defined value. If one 
of the proposed functions is called with a variable which isn't an array 
or an empty array (or even a call with no parameter) there is neither a 
first nor a last key and thus null is the value which is returned.

Compare the tests for the error cases:
https://github.com/php/php-src/pull/3256/files#diff-e00a584724b997f38e851e15f1e20c39

This behavior is also implemented in existing functions like eg. 
array_pop():

https://github.com/php/php-src/blob/master/ext/standard/tests/array/array_pop_errors.phpt

Enno


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

[PHP-DEV] Re: [RFC][Under Discussion] Add functions array_key_first() and array_key_last()

[Enno Woortmann]

Hi,

On 13.06.2018 at 23:10, Christoph M. Becker wrote:


I suggest to address Côme's suggestion[1] on this mailing list and
especially in the RFC (the template[2] offers “Open Issues” and
“Rejected Features” sections).

[1] 



I've added the "Open Issues" section to the RFC and added the idea of Côme and 
Gabriel to add the corresponding functions for handling the values of the outer elements 
of an array to provide a complete set of functions.
Currently I see three possibilities to handle the idea. Either extend the scope 
of the RFC to cover also the handling of the values, which could be implemented 
rather fast and by reusing a lot of code as the current implementation already 
gathers the bucket for the first/last element of an array, or move this idea to 
a future scope which should be covered by a separate RFC. The third alternative 
would be to skip the implementation of the corresponding functions.

In my opinion it's a good idea to complete the function set by also providing 
functions for the handling of array values. Both opportunities which would lead 
to the completed set are practicable in my view.

Any opinions concerning this issue?

Good night (or day, wherever you are ;) ),
Enno



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

[PHP-DEV] [RFC][Under Discussion] Add functions array_key_first() and array_key_last()

[Enno Woortmann]

Hello internals,

I've changed the status of the currently introduced RFC to add the 
functions array_key_first() and array_key_last() to "Under Discussion".


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

Regards,

Enno



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

[PHP-DEV] Re: Add functions array_key_first() and array_key_last()

[Enno Woortmann]

Hi Christoph,

On 11.06.2018 at 15:21, Christoph M. Becker wrote:


You should have RFC karma now.


Thanks for the RFC karma, everything worked fine.

I've created a new RFC for this topic located at 
https://wiki.php.net/rfc/array_key_first_last

Thanks,
Enno


---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus


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

[PHP-DEV] Add functions array_key_first() and array_key_last()

[Enno Woortmann]

Hello Internals,

I'd like to ask for feedback for my idea.
Some years ago a pull request came up to add array_key_first(),
array_key_last(), and array_key_index() functions (#347
).
In the meantime a RFC was published to integrate the functions
(https://wiki.php.net/rfc/array_key_first_last_index) which was
discussed in the mailing list two and a half years ago
(https://externals.io/message/89955).

Since the pull request and the RFC doesn't sustain a real progress and
in my opinion at least the functions array_key_first(array $a) and
array_key_last(array $a) would be handy in some cases I'd like to
propose using a smaller functional scope as a first step including only
this two functions.
Additional features like returning the value of the requested element or
the function array_key_index() could be implemented in a later stage if
required.

I implemented those two functions in a different implementation approach
which tries to use as much existing code as possible available and
already created a pull request at https://github.com/php/php-src/pull/3256.

For the next steps I'd like to create a new RFC as the functional scope
differs to the existing RFC. Therefor I request a PHP.net wiki account
(wiki username: wol-soft) to create a new RFC.

Regards,
Enno



---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus