Hello,
"Since we can define array element by reference now, it doesn't make sense
to change the way of storing values just because it's unpacking. In other
words, the conversion of how values are stored isn't part of spread
operator."
yes it is; no matter what you "think"; banding reality/facts
On Monday, April 8, 2019 9:22 PM Nikita Popov wrote:
> This looks reasonable to me. My only concern would be the "by-reference
> passing" section of the RFC. The current proposal states that [...$arr] will
> preserve references in $arr, which is not the behavior I would expect.
>
> Is this
> Le 13 avr. 2019 à 11:09, Stijn Peeters a écrit :
>
> Is anyone aware of other arguments for not allowing normal arguments after
> unpackable arguments in function calls?
I've grabbed into the archives of internals. Apart from technical issues:
The main argument against that affordance was
On 13 April 2019 10:09:20 BST, Stijn Peeters wrote:
>Is anyone aware of other arguments for not allowing normal arguments
>after
>unpackable arguments in function calls?
CHU Zhaowei pointed to this git commit which suggests it's an implementation
issue rather than a design decision:
"Dan Ackroyd" schreef op 6 april 2019 07:37:
> On Fri, 5 Apr 2019 at 09:03, Claude Pache wrote:
>
>> That begs the question: why is this invalid for function calls?
>
> At least in part, because if we ever wanted to add a standard
> _toArray() method, like we have __toString(), it would be
Le vendredi 5 avril 2019, 11:00:59 CEST Michał Brzuchalski a écrit :
> So we're talking about providing incomplete feature now, right?
As I understand it, the point is to make unpacking available to arrays, to be
consistent with function calls.
// This is already supported
$result =
On Thu, Apr 4, 2019 at 4:15 PM CHU Zhaowei wrote:
> Hi internals,
>
> Thanks for the people who joined the discussion of my [RFC: Spread
> Operator in Array Expression](
> https://wiki.php.net/rfc/spread_operator_for_array). The biggest change
> is I have dropped the support for string keys in
On Fri, 5 Apr 2019 at 09:03, Claude Pache wrote:
>
> That begs the question: why is this invalid for function calls?
At least in part, because if we ever wanted to add a standard
_toArray() method, like we have __toString(), it would be quite a
massive BC break if we already made it so that PHP
: Michał Brzuchalski
Sent: Friday, April 5, 2019 5:01 PM
To: Rowan Collins
Cc: PHP internals
Subject: Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2
pt., 5 kwi 2019 o 10:50 Rowan Collins napisał(a):
>
> The original draft discussed this, but there wasn't agreement on how
>
see the same limit exists for arrays, so I didn't include this rule in
my RFC.
Thanks,
CHU Zhaowei
-Original Message-
From: Claude Pache
Sent: Friday, April 5, 2019 4:04 PM
To: Stijn Peeters
Cc: CHU Zhaowei ; PHP internals
Subject: Re: [PHP-DEV] [RFC] Spread Operator in Array
pt., 5 kwi 2019 o 10:50 Rowan Collins napisał(a):
>
> The original draft discussed this, but there wasn't agreement on how
> identical keys should be handled, e.g.:
>
> $a = ['foo' => 1, ...['foo' => 2]]
>
> Should $['foo'] be 1 or 2? Cases were made for both, and it was pointed out
> that if we
On Fri, 5 Apr 2019 at 09:31, Michał Brzuchalski
wrote:
> The next paragraph in MDN document is spread operator for object literals
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax#Spread_in_object_literals
> Now JavaScript objects can be used like our
pt., 5 kwi 2019 o 08:56 CHU Zhaowei napisał(a):
> Here is a MDN document for spread operator in JS:
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax#Spread_in_array_literals
> and hope you find more useful examples.
>
The next paragraph in MDN document
> Le 5 avr. 2019 à 09:45, Stijn Peeters a écrit :
>
> Hi,
>
> If I understand correctly it is possible in this proposal to use normal
> arguments after using an unpackable argument:
>
> $arr4 = array(...$arr1, ...$arr2, 111); //valid
>
> This is something that is not possible when
Hi,
If I understand correctly it is possible in this proposal to use normal
arguments after using an unpackable argument:
$arr4 = array(...$arr1, ...$arr2, 111); //valid
This is something that is not possible when using argument unpacking in
function calls:
$result =
:40 AM
To: Derick Rethans
Cc: CHU Zhaowei ; PHP internals
Subject: Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2
On Thu, 4 Apr 2019 at 17:14, Derick Rethans wrote:
> Could you add to the RFC what the exact pain point is that this is
> trying to address? It looks a littl
] Spread Operator in Array Expression v0.2
> On 4 Apr 2019, at 21:14, CHU Zhaowei wrote:
>
> Hi internals,
>
> Thanks for the people who joined the discussion of my [RFC: Spread Operator
> in Array Expression](https://wiki.php.net/rfc/spread_operator_for_array). The
> big
> On 4 Apr 2019, at 21:14, CHU Zhaowei wrote:
>
> Hi internals,
>
> Thanks for the people who joined the discussion of my [RFC: Spread Operator
> in Array Expression](https://wiki.php.net/rfc/spread_operator_for_array). The
> biggest change is I have dropped the support for string keys in
On Thu, 4 Apr 2019 at 17:14, Derick Rethans wrote:
> Could you add to the RFC what the exact pain point is that this is
> trying to address? It looks a little like this is just adding syntax for
> the sake of it.
>
Not everything is about pain, some things are just about gain. ;)
The link
Hi!
On Thu, 4 Apr 2019, CHU Zhaowei wrote:
> Thanks for the people who joined the discussion of my [RFC: Spread
> Operator in Array
> Expression](https://wiki.php.net/rfc/spread_operator_for_array). The
> biggest change is I have dropped the support for string keys in v0.2
> as suggested by
On Thu, Apr 4, 2019 at 9:58 AM Michał Brzuchalski
wrote:
>
> Hi CHU Zhaowei,
>
> Where can I find first RFC version? Revisited RFCs AFAIK should be served
> under different name.
Look at its history. Using the same URL is fine, as long as author(s) agree.
> Personally I liked key preserve
Hi CHU Zhaowei,
Where can I find first RFC version? Revisited RFCs AFAIK should be served
under different name.
Personally I liked key preserve behavior. Without it use of spread operator
I array expression would have minor use. But this is my personal feeling
about only.
I think I'm missing
22 matches
Mail list logo
