Re: [PHP-DEV] Array functions with strict comparison

2023-11-14 Thread Andreas Hennings
On Tue, 14 Nov 2023 at 18:49, Robert Landers wrote: > > On Tue, Nov 14, 2023 at 1:39 PM Andreas Hennings wrote: > > > > Hello Robert, > > > > On Tue, 14 Nov 2023 at 11:09, Robert Landers > > wrote: > > > > > > Andreas, > > > > > > Just out of curiosity, what is the use case for this? I can't re

Re: [PHP-DEV] Array functions with strict comparison

2023-11-14 Thread Craig Francis
On 14 Nov 2023, at 17:49, Robert Landers wrote: > One of the most beautiful things about PHP is that null == 0 == false, or '5' > == 5 == 5.0, or 1 == true == 'hello world', which is so incredibly handy in > web-dev that to ignore it is inviting bugs. Headers may or may not be set, > form value

Re: [PHP-DEV] Array functions with strict comparison

2023-11-14 Thread Robert Landers
On Tue, Nov 14, 2023 at 1:39 PM Andreas Hennings wrote: > > Hello Robert, > > On Tue, 14 Nov 2023 at 11:09, Robert Landers wrote: > > > > Andreas, > > > > Just out of curiosity, what is the use case for this? I can't really > > think of a practical case where strict checking is needed for these >

Re: [PHP-DEV] Array functions with strict comparison

2023-11-14 Thread Andreas Hennings
On Tue, 14 Nov 2023 at 02:08, David Gebler wrote: > > On Sun, Nov 12, 2023 at 8:20 PM Andreas Hennings > wrote: > > > So to me, this alone is an argument to implement this natively. > > The other argument is that it is kind of sad how the current functions > > don't behave as one would expect. >

Re: [PHP-DEV] Array functions with strict comparison

2023-11-14 Thread Andreas Hennings
Hello Robert, On Tue, 14 Nov 2023 at 11:09, Robert Landers wrote: > > Andreas, > > Just out of curiosity, what is the use case for this? I can't really > think of a practical case where strict checking is needed for these > functions. Usually, you have a really good idea of what is in the > array

Re: [PHP-DEV] Array functions with strict comparison

2023-11-14 Thread Robert Landers
Andreas, Just out of curiosity, what is the use case for this? I can't really think of a practical case where strict checking is needed for these functions. Usually, you have a really good idea of what is in the arrays when writing the code and can handle any edge cases (like nulls, empty strings,

Re: [PHP-DEV] Array functions with strict comparison

2023-11-13 Thread David Gebler
On Sun, Nov 12, 2023 at 8:20 PM Andreas Hennings wrote: > So to me, this alone is an argument to implement this natively. > The other argument is that it is kind of sad how the current functions > don't behave as one would expect. I'd expect there to be a larger and proportionately increasing p

Re: [PHP-DEV] Array functions with strict comparison

2023-11-12 Thread Andreas Hennings
On Sat, 11 Nov 2023 at 20:43, Andreas Hennings wrote: > > Hello David, > > On Sat, 11 Nov 2023 at 20:04, David Gebler wrote: > > > > On Sat, Nov 11, 2023 at 6:05 PM Andreas Hennings > > wrote: > > > > > Hello internals, > > > I noticed that array functions like array_diff(), array_intersect() >

Re: [PHP-DEV] Array functions with strict comparison

2023-11-11 Thread Andreas Hennings
Hello David, On Sat, 11 Nov 2023 at 20:04, David Gebler wrote: > > On Sat, Nov 11, 2023 at 6:05 PM Andreas Hennings > wrote: > > > Hello internals, > > I noticed that array functions like array_diff(), array_intersect() > > etc use weak comparison. > > > > > That's not quite correct. Using the e

Re: [PHP-DEV] Array functions with strict comparison

2023-11-11 Thread David Gebler
On Sat, Nov 11, 2023 at 6:05 PM Andreas Hennings wrote: > Hello internals, > I noticed that array functions like array_diff(), array_intersect() > etc use weak comparison. > > That's not quite correct. Using the example of array_diff, the comparison is a strict equality check on a string cast of

[PHP-DEV] Array functions with strict comparison

2023-11-11 Thread Andreas Hennings
Hello internals, I noticed that array functions like array_diff(), array_intersect() etc use weak comparison. E.g. array_diff([0, '', false, null], [null]) only leaves [0]. This makes these functions useless for a number of applications. Also it can lead to unpleasant surprises, if a developer is

[PHP-DEV] Re: Allowing $a = foo($a) to operate in-place (was Re: [PHP-DEV] Array spread append)

2023-04-10 Thread Niels Dossche
Hi On 10/04/2023 22:11, Tim Düsterhus wrote: > Hi > > On 4/10/23 21:50, Niels Dossche wrote: >>> The suggested optimization of "the input is overwritten with the output" >>> would then also allow to avoid introducing reference parameters just for >>> optimization purposes. The sort() family com

[PHP-DEV] Allowing $a = foo($a) to operate in-place (was Re: [PHP-DEV] Array spread append)

2023-04-10 Thread Tim Düsterhus
Hi On 4/10/23 21:50, Niels Dossche wrote: The suggested optimization of "the input is overwritten with the output" would then also allow to avoid introducing reference parameters just for optimization purposes. The sort() family comes to my mind and also the shuffle() function. Randomizer::sh

Re: [PHP-DEV] Array spread append

2023-04-10 Thread Niels Dossche
Hey Tim On 10/04/2023 14:45, Tim Düsterhus wrote: > Hi > > On 4/8/23 22:17, Niels Dossche wrote: >> I think this could be made more generic, and be cleaned up. >> But I don't know if something like this is desired in PHP. > > Yes, please. I believe that “performance” should not influence API des

Re: [PHP-DEV] Array spread append

2023-04-10 Thread Tim Düsterhus
Hi On 4/8/23 22:17, Niels Dossche wrote: I think this could be made more generic, and be cleaned up. But I don't know if something like this is desired in PHP. Yes, please. I believe that “performance” should not influence API design if it can be avoided. Instead the heavy lifting of optimiza

Re: [PHP-DEV] Array spread append

2023-04-09 Thread Hans Krentel via internals
On Saturday 08 April 2023 22:17:14 (+02:00), Niels Dossche wrote: > However, I think it might be worth adding an optimization for the most common $x = array_merge($x, ...) case. If so, then syntax wise I'd throw that suggestion in the ring: $x[] = ... $y ; This would allow to adopt exi

Re: [PHP-DEV] Array spread append

2023-04-08 Thread Niels Dossche
Hi On 4/6/23 00:12, Vorisek, Michael wrote: > Hello, > > I would like to open a discussion for > https://github.com/php/php-src/issues/10791 . > [https://opengraph.githubassets.com/a23cb565cc8acac6a33ecab5d9ee68a46f046a1ffe215501673156e506695430/php/php-src/issues/10791]

Re: [PHP-DEV] Array spread append

2023-04-07 Thread Bob Magic
> I think it would be more intuitive to implement an array "appending" > functionality with "concatenating" syntax. The `.=` syntax already exists, > but is forbidden from use on non-strings. If you want to implement this > preexisting syntax as an array concatenation operator, then it is a blan

Re: [PHP-DEV] Array spread append

2023-04-07 Thread Tim Düsterhus
Hi On 4/6/23 00:12, Vorisek, Michael wrote: I would like to open a discussion for https://github.com/php/php-src/issues/10791 . For the discussion phase to actually be open (with regard to the minimal discussion period before a vote on an RFC may be opened), an actual RFC needs to exist.

Re: [PHP-DEV] Array spread append

2023-04-06 Thread Vorisek, Michael
5:01 PM To: Vorisek, Michael Cc: PHP internals Subject: Re: [PHP-DEV] Array spread append czw., 6 kwi 2023, 13:53 użytkownik Vorisek, Michael mailto:voris...@fjfi.cvut.cz>> napisał: Hi Ilija, * Are integer keys preserved? I'm assuming no, as otherwise it would be the same as `$a +

Re: [PHP-DEV] Array spread append

2023-04-06 Thread Michał Marcin Brzuchalski
czw., 6 kwi 2023, 13:53 użytkownik Vorisek, Michael napisał: > Hi Ilija, > > * Are integer keys preserved? I'm assuming no, as otherwise it would > be the same as `$a + $b`. > > $arr[...] = $arr; > should be the same as > foreach ($arr as $v) { $arr[] = $v; } > I'd argue with that because I thin

Re: [PHP-DEV] Array spread append

2023-04-06 Thread G. P. B.
On Thu, 6 Apr 2023 at 14:04, mickmackusa wrote: > I think it would be more intuitive to implement an array "appending" > functionality with "concatenating" syntax. The `.=` syntax already exists, > but is forbidden from use on non-strings. If you want to implement this > preexisting syntax as a

Re: [PHP-DEV] Array spread append

2023-04-06 Thread mickmackusa
> > > * Are integer keys preserved? I'm assuming no, as otherwise it would > be the same as `$a + $b`. > > $arr[...] = $arr; > should be the same as > foreach ($arr as $v) { $arr[] = $v; } > > all other answers should be answered from this and consistency Since `$arr1[...] = $arr2;` should be con

Re: [PHP-DEV] Array spread append

2023-04-06 Thread Vorisek, Michael
02Cq - `$arr[...] = &$arr` should be compile error Michael From: Ilija Tovilo Sent: Thursday, April 6, 2023 12:18 PM To: internals@lists.php.net Subject: Re: [PHP-DEV] Array spread append Hi Michael > I would like to open a discussion for > https://

Re: [PHP-DEV] Array spread append

2023-04-06 Thread Ilija Tovilo
Hi Michael > I would like to open a discussion for > https://github.com/php/php-src/issues/10791 . > [https://opengraph.githubassets.com/a23cb565cc8acac6a33ecab5d9ee68a46f046a1ffe215501673156e506695430/php/php-src/issues/10791] > Array spread append ·

Re: [PHP-DEV] Array spread append

2023-04-06 Thread Michał Marcin Brzuchalski
Hi Mick czw., 6 kwi 2023 o 10:00 mickmackusa napisał(a): > Call me sentimental, but are we just trying to choke out the few remaining > reasons to keep array_push() in the language? > > Okay, yeah, sometimes at is a drag that the first parameter has to be > declared in advance and is modified by

Re: [PHP-DEV] Array spread append

2023-04-06 Thread mickmackusa
Call me sentimental, but are we just trying to choke out the few remaining reasons to keep array_push() in the language? Okay, yeah, sometimes at is a drag that the first parameter has to be declared in advance and is modified by reference (which means you can't enjoy null coalescing or short tern

Re: [PHP-DEV] Array spread append

2023-04-05 Thread Andreas Hennings
> I have the feeling I'm missing something, but how would this compare to array join Array join does neither append nor replace if a numeric index already exists. But you can do [...$arr0, ...$arr1]. https://3v4l.org/CIinR print json_encode([ [...['a', 'b'], ...['c', 'd']], // [a, b, c, d]

Re: [PHP-DEV] Array spread append

2023-04-05 Thread Juliette Reinders Folmer
On 6-4-2023 0:12, Vorisek, Michael wrote: Hello, I would like to open a discussion for https://github.com/php/php-src/issues/10791 . [https://opengraph.githubassets.com/a23cb565cc8acac6a33ecab5d9ee68a46f046a1ffe215501673156e506695430/php/php-src/issues/10791]

[PHP-DEV] Array spread append

2023-04-05 Thread Vorisek, Michael
Hello, I would like to open a discussion for https://github.com/php/php-src/issues/10791 . [https://opengraph.githubassets.com/a23cb565cc8acac6a33ecab5d9ee68a46f046a1ffe215501673156e506695430/php/php-src/issues/10791] Array spread append · Issue #10791

Re: [PHP-DEV] Array comparison works completely different than documented?

2021-12-01 Thread G. P. B.
On Wed, 1 Dec 2021 at 13:56, André Hänsel wrote: > The official documentation contains a conceptual description of array > comparison in > https://www.php.net/manual/en/language.operators.comparison.php#example-113 > . > > Curiously the people who wrote the inofficial spec (I think the HHVM team

[PHP-DEV] Array comparison works completely different than documented?

2021-12-01 Thread André Hänsel
The official documentation contains a conceptual description of array comparison in https://www.php.net/manual/en/language.operators.comparison.php#example-113. Curiously the people who wrote the inofficial spec (I think the HHVM team at Facebook?) came to pretty much the same result, described in

[PHP-DEV] Array recursion detection in PHP 8

2020-09-23 Thread Michael Wallner
Hi, I wondered about PHP 8 detecting recursion earlier than used to and what caused that, respectively why it's caused. Compare the following output: https://3v4l.org/J7Niu Thanks in advance for any hints! -- Regards, Mike signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] Array map with reset function

2020-08-27 Thread Alexandru Pătrănescu
On Wed, Aug 26, 2020 at 11:16 AM Rowan Tommins wrote: > > On Tue, 25 Aug 2020 at 20:08, Nikita Popov wrote: > > > On Tue, Aug 25, 2020 at 7:47 PM Michael Voříšek - ČVUT FEL < > > voris...@fel.cvut.cz> wrote: > > > > > The following code stopped working in PHP 8: > > > > > > https://3v4l.org/UlIE3

Re: [PHP-DEV] Array map with reset function

2020-08-26 Thread Rowan Tommins
On Tue, 25 Aug 2020 at 20:08, Nikita Popov wrote: > On Tue, Aug 25, 2020 at 7:47 PM Michael Voříšek - ČVUT FEL < > voris...@fel.cvut.cz> wrote: > > > The following code stopped working in PHP 8: > > > > https://3v4l.org/UlIE3 To be pedantic: it didn't stop working, it just started raising Warn

Re: [PHP-DEV] Array map with reset function

2020-08-25 Thread Nikita Popov
On Tue, Aug 25, 2020 at 7:47 PM Michael Voříšek - ČVUT FEL < voris...@fel.cvut.cz> wrote: > The following code stopped working in PHP 8: > > https://3v4l.org/UlIE3 > > is it a bug or a feature? > This is an intentional change, if that's what you're asking. array_map() is not spec'd to pass by ref

Re: [PHP-DEV] Array map with reset function

2020-08-25 Thread Levi Morrison via internals
On Tue, Aug 25, 2020 at 11:47 AM Michael Voříšek - ČVUT FEL wrote: > > The following code stopped working in PHP 8: > > https://3v4l.org/UlIE3 > > is it a bug or a feature? > > is posting issues like this to internals@lists.php.net email prefered > over opening bug directly? or is there any specia

[PHP-DEV] Array map with reset function

2020-08-25 Thread Michael Voříšek - ČVUT FEL
The following code stopped working in PHP 8: https://3v4l.org/UlIE3 is it a bug or a feature? is posting issues like this to internals@lists.php.net email prefered over opening bug directly? or is there any special email for it? With kind regards / Mit freundlichen Grüßen / S přátelským p

[PHP-DEV] Array comparison with strict operators

2020-04-21 Thread Arnold Daniels
Hi all, In preparation for restarting the discussion on the strict operators RFC, I'm critically looking at cases where no TypeError is thrown, but the behavior changes instead. Comparing two arrays using `==` is particularly fuzzy at the moment. An array in PHP is actually an ordered map. Usi

Re: [PHP-DEV] Array max size

2018-08-01 Thread Sara Golemon
On Wed, Aug 1, 2018 at 2:41 PM, Marcos Passos wrote: > Whenever you look for more information about the maximum size of an array, > you find someone saying that "PHP arrays do not have a maximum size, but > the amount of memory available". However, I could not find any excerpt in > PHP documentati

Re: [PHP-DEV] Array max size

2018-08-01 Thread Marcos Passos
If you are arguing strictly about not knowing what to write on the documentation, let's move the discussion towards whether it should be defined or not. 2018-08-01 16:51 GMT-03:00 Sherif Ramadan : > Right, and therein lies the problem. No one has ever defined this > behavior. As such, one cannot

Re: [PHP-DEV] Array max size

2018-08-01 Thread Sherif Ramadan
Right, and therein lies the problem. No one has ever defined this behavior. As such, one cannot document what has never been defined. What you're describing is UNdefined. Undefined things cannot be documented. On Wed, Aug 1, 2018, 3:46 PM Marcos Passos wrote: > *The point is not about the poss

Re: [PHP-DEV] Array max size

2018-08-01 Thread Marcos Passos
*The point is not about the possibility of crossing the limit of the array, but the need for a definition so one can design a method or function whose behavior aligns with the array capabilities. This need, in fact, became more noticeable from a design point of view since the introduction of the it

Re: [PHP-DEV] Array max size

2018-08-01 Thread Marcos Passos
It looks like the limit I mentioned, used by some functions, is architecture-dependent: https://github.com/php/php-src/blob/master/Zend/zend_types.h#L288 Also, that's such a ridiculously large number for the vast majority of > people using PHP that hardly anyone ever runs into this limit. The po

Re: [PHP-DEV] Array max size

2018-08-01 Thread Sherif Ramadan
It's undocumented, because it's considered undefined behavior. PHP arrays implicitly store the number of elements internally as an unsigned 32 bit integer (regardless of architecture). This means that (technically) you can't create an array with more than ((2**31) - 1) elements (or 2,147,483,647 el

Re: [PHP-DEV] Array max size

2018-08-01 Thread Levi Morrison
On Wed, Aug 1, 2018 at 12:42 PM Marcos Passos wrote: > > Whenever you look for more information about the maximum size of an array, > you find someone saying that "PHP arrays do not have a maximum size, but > the amount of memory available". However, I could not find any excerpt in > PHP documenta

Re: [PHP-DEV] Array max size

2018-08-01 Thread Levi Morrison
On Wed, Aug 1, 2018 at 12:42 PM Marcos Passos wrote: > > Whenever you look for more information about the maximum size of an array, > you find someone saying that "PHP arrays do not have a maximum size, but > the amount of memory available". However, I could not find any excerpt in > PHP documenta

Re: [PHP-DEV] Array max size

2018-08-01 Thread Lester Caine
On 01/08/18 19:41, Marcos Passos wrote: My understanding is that the conceptual limit is*PHP_INT_MAX*, as there is no way to represent the size above this value. And on which definition, 32bit versions of PHP crash out before 64bit builds ... It assumes that one HAS to convert variables to bin

[PHP-DEV] Array max size

2018-08-01 Thread Marcos Passos
Whenever you look for more information about the maximum size of an array, you find someone saying that "PHP arrays do not have a maximum size, but the amount of memory available". However, I could not find any excerpt in PHP documentation that supports that. Even if the engine imposes no hard lim

Re: [PHP-DEV] array coalesce operator concept

2017-07-13 Thread Walter Parker
On Thu, Jul 13, 2017 at 2:55 AM, Tony Marston wrote: > "David Rodrigues" wrote in message news:CAEsg9X2ECG62i7Z_Nu11kqr7 > yvbkmucd3mxgt78ulampfx-...@mail.gmail.com... > >> >> The idea is good, but I don't know if it is more clear than an 'if()' >> > > I think that this proposal is totally ridic

Re: [PHP-DEV] array coalesce operator concept

2017-07-13 Thread Tony Marston
"David Rodrigues" wrote in message news:caesg9x2ecg62i7z_nu11kqr7yvbkmucd3mxgt78ulampfx-...@mail.gmail.com... The idea is good, but I don't know if it is more clear than an 'if()' I think that this proposal is totally ridiculous and should be shot down in flames. My reasoning is as follows:

Re: [PHP-DEV] array coalesce operator concept

2017-07-13 Thread Niklas Keller
> > 2017-07-12 22:14 GMT+02:00 Niklas Keller : > > > 2017-07-12 17:26 GMT+02:00 Michał Brzuchalski < > > michal.brzuchal...@gmail.com>: > > > >> 12.07.2017 15:35 "Mark Shust" napisał(a): > >> > > >> > Hi Aidan, > >> > > >> > I think you are correct on all points. The initial emit is just a > >> wa

Re: [PHP-DEV] array coalesce operator concept

2017-07-13 Thread Michał Brzuchalski
2017-07-12 22:14 GMT+02:00 Niklas Keller : > 2017-07-12 17:26 GMT+02:00 Michał Brzuchalski < > michal.brzuchal...@gmail.com>: > >> 12.07.2017 15:35 "Mark Shust" napisał(a): >> > >> > Hi Aidan, >> > >> > I think you are correct on all points. The initial emit is just a >> warning, >> > so I think

Re: [PHP-DEV] array coalesce operator concept

2017-07-12 Thread Niklas Keller
2017-07-12 17:26 GMT+02:00 Michał Brzuchalski : > 12.07.2017 15:35 "Mark Shust" napisał(a): > > > > Hi Aidan, > > > > I think you are correct on all points. The initial emit is just a > warning, > > so I think a suppressor will work just fine, since it does just pass over > > the foreach if a tr

Re: [PHP-DEV] array coalesce operator concept

2017-07-12 Thread Mark Shust
Stas, Wow, for some reason it didn't occur to me to try that. Confirming the following works: foreach ($foo ?? [] as $bar) { echo $bar; } I think the biggest need for this is if the value is null. Guess it's case-closed :) Might be a good idea to add this to the docs, pretty neat. Mark

Re: [PHP-DEV] array coalesce operator concept

2017-07-12 Thread Stanislav Malyshev
Hi! > Code will error if a non-array value is passed through a looping feature. > For example, this code: > > > $foo = "abc"; > > foreach ($foo as $bar) { Looks like $foo??[] would work here. If $foo is something like false or null, that is. If it's not, this is probably a serious bug (why wo

Re: [PHP-DEV] array coalesce operator concept

2017-07-12 Thread Aidan Woods
> That said, another possibility I thought of is automatically converting whatever is passed into a foreach loop to > be cast into an iterable/array for the duration of the loop. I'm wondering what opinions would be on the cons of > going this route. Given php's weak typing and someone's desire to

Re: [PHP-DEV] array coalesce operator concept

2017-07-12 Thread Mark Shust
I agree, error suppression is generally ugly/nasty behavior that is a hack to the language. I also agree that if it's there now, @as is a pretty good use for it. That said, another possibility I thought of is automatically converting whatever is passed into a foreach loop to be cast into an iterab

Re: [PHP-DEV] array coalesce operator concept

2017-07-12 Thread Aidan Woods
> IMHO the whole error supression and its operator should be deprecated and removed from language. > Supressing errors is just hiding problems because someone didn't want to solve it. Supressing errors > makes debuging very hard and leads to frustration. I can concur with disliking the error suppr

Re: [PHP-DEV] array coalesce operator concept

2017-07-12 Thread Andreas Treichel
> PHP already exhibits the skipping behaviour (it only emits a warning > for the wrong type used in `foreach`, skips the loop, and then > continues with remaining code). Yes, a warning is not an error. If someone dont care about warnings from error prone code, set the error_reporting accordingly

Re: [PHP-DEV] array coalesce operator concept

2017-07-12 Thread Michał Brzuchalski
12.07.2017 15:35 "Mark Shust" napisał(a): > > Hi Aidan, > > I think you are correct on all points. The initial emit is just a warning, > so I think a suppressor will work just fine, since it does just pass over > the foreach if a traversable isn't passed in. > > I could see this being helpful as i

Re: [PHP-DEV] array coalesce operator concept

2017-07-12 Thread Mark Shust
Hi Aidan, I think you are correct on all points. The initial emit is just a warning, so I think a suppressor will work just fine, since it does just pass over the foreach if a traversable isn't passed in. I could see this being helpful as it makes wrapping an if block around a foreach not needed

Re: [PHP-DEV] array coalesce operator concept

2017-07-12 Thread Aidan Woods
In theory you'd only *need* it be considered a suppressor? PHP already exhibits the skipping behaviour (it only emits a warning for the wrong type used in `foreach`, skips the loop, and then continues with remaining code). No harm in/there is probably value in, making that skipping intent explicit

Re: [PHP-DEV] array coalesce operator concept

2017-07-11 Thread Mark Shust
Aidan, Fantastic suggestion (@as) -- that is really the succinctness I was initially looking for, and I think the intention makes a lot of sense. My only concern/issue would be to make sure that isn't considered a 'suppressor' -- but it's actual intent is to skip the execution of the foreach to pr

Re: [PHP-DEV] array coalesce operator concept

2017-07-11 Thread Aidan Woods
If you were willing to accept ``` foreach ($foo as $bar) if (is_array) { ... } ``` as a solution, then you might as well use ``` if (is_array($foo)) foreach ($foo as $bar) { ... } ``` I wonder if this could be better achieved by expanding what the error suppression operator `@` can do? This ent

Re: [PHP-DEV] array coalesce operator concept

2017-07-11 Thread Mark Shust
Thanks for the great feedback. Based on the last mindset on keyword syntax, this comes to mind, intended to be used similarly to the 'use' keyword when used within the context of a closure: foreach ($foo as $bar) if (is_array) { ... } I don't think this is a vast improvement over wrapping this

Re: [PHP-DEV] array coalesce operator concept

2017-07-11 Thread Rowan Collins
On 11 July 2017 16:02:18 BST, Mark Shust wrote: >For a syntactic >sugar/improvement, this can be shorthand for executing the loop instead >of >wrapping the block within an is_array check: > > > >$foo = "abc"; > >foreach (??$foo as $bar) { > > echo $bar; > >} Hi! I think there's definitely the s

Re: [PHP-DEV] array coalesce operator concept

2017-07-11 Thread Ivan Enderlin
Hello :-), Thank you for the proposal. I have a question though: How is it different from: * `foreach ($foo ?: [] as $bar) { … }` if `$foo` does not exist, * `foreach ((array) $foo as $bar) { … }` if `$foo` is not an array. I understand your issue, but you can probably type your data with `

Re: [PHP-DEV] array coalesce operator concept

2017-07-11 Thread David Rodrigues
The idea is good, but I don't know if it is more clear than an 'if()' Em 11 de jul de 2017 12:15 PM, "Mark Shust" escreveu: > Hello, > > I wanted to garnish feedback on a RFC proposal. This is just a concept at > this point, and is inspired by the null coalesce operator. > > Code will error if a

[PHP-DEV] array coalesce operator concept

2017-07-11 Thread Mark Shust
Hello, I wanted to garnish feedback on a RFC proposal. This is just a concept at this point, and is inspired by the null coalesce operator. Code will error if a non-array value is passed through a looping feature. For example, this code:

Re: [PHP-DEV] Array key access on non-array values - to be made illegal?

2016-04-12 Thread Kalle Sommer Nielsen
On Apr 12, 2016 15:02, "Ivan Enderlin" wrote: > > Hello Marco, > > Actually, you are trying to access to something that does not exist, so you get a null value. This part is logical. However, yes, a notice would be welcomed except it may be skipped for historical reasons I reckon. Probably to work

Re: [PHP-DEV] Array key access on non-array values - to be made illegal?

2016-04-12 Thread Ivan Enderlin
Hello Marco, Actually, you are trying to access to something that does not exist, so you get a null value. This part is logical. However, yes, a notice would be welcomed except it may be skipped for historical reasons I reckon. Probably to work well with `isset` or similar scenario. Cheers.

[PHP-DEV] Array key access on non-array values - to be made illegal?

2016-04-12 Thread Marco Pivetta
Hello, I just stumbled upon behavior that seems to "fail silently" regardless of its very questionable validity: https://3v4l.org/b3rDr Are there specific reasons why no notice is thrown? Is it by design? If so, does anyone remember why? I haven't checked if this affects other types too. I know

Re: [PHP-DEV] Array dereferencing of scalars

2015-06-14 Thread Rowan Collins
On 14 June 2015 04:33:16 BST, Yasuo Ohgaki wrote: >Hi Rowan, > >On Thu, Jun 11, 2015 at 5:59 PM, Rowan Collins > >wrote: >> This one has given a different message because of it being a >non-string >> value, but would be equally fatal if you tried to call any undefined >> function. Would coercing N

Re: [PHP-DEV] Array dereferencing of scalars

2015-06-13 Thread Yasuo Ohgaki
Hi all, On Fri, Jun 12, 2015 at 9:36 AM, Chris Wright wrote: > On 12 June 2015 at 00:35, Rowan Collins wrote: > > > On 11/06/2015 21:22, Chris Wright wrote: > > > >> I'm inclined to agree that we should have consistency here, and that the > >> current behaviour in a function context is the corr

Re: [PHP-DEV] Array dereferencing of scalars

2015-06-13 Thread Yasuo Ohgaki
Hi Rowan, On Thu, Jun 11, 2015 at 5:59 PM, Rowan Collins wrote: > Yasuo Ohgaki wrote on 11/06/2015 00:50: > >> If PHP should return NULL always against NULL variables, we may be better >> to >> reconsider these behavior. >> >> [yohgaki@dev Download]$ php >> > $v = NULL; >> $$v; >> >> >> PHP Noti

Re: [PHP-DEV] Array dereferencing of scalars

2015-06-11 Thread Chris Wright
On 12 June 2015 at 00:35, Rowan Collins wrote: > On 11/06/2015 21:22, Chris Wright wrote: > >> I'm inclined to agree that we should have consistency here, and that the >> current behaviour in a function context is the correct one. A couple of >> (IMO) good arguments for this: >> >> - The function

Re: [PHP-DEV] Array dereferencing of scalars

2015-06-11 Thread Rowan Collins
On 11/06/2015 21:22, Chris Wright wrote: I'm inclined to agree that we should have consistency here, and that the current behaviour in a function context is the correct one. A couple of (IMO) good arguments for this: - The function behaviour gives a more explanatory and useful error message -

Re: [PHP-DEV] Array dereferencing of scalars

2015-06-11 Thread Chris Wright
On 11 June 2015 at 09:59, Rowan Collins wrote: > Yasuo Ohgaki wrote on 11/06/2015 00:50: > >> If PHP should return NULL always against NULL variables, we may be better >> to >> reconsider these behavior. >> >> [yohgaki@dev Download]$ php >> > $v = NULL; >> $$v; >> >> >> PHP Notice: Undefined var

Re: [PHP-DEV] Array dereferencing of scalars

2015-06-11 Thread Rowan Collins
Yasuo Ohgaki wrote on 11/06/2015 00:50: If PHP should return NULL always against NULL variables, we may be better to reconsider these behavior. [yohgaki@dev Download]$ php This is not complaining that $v is NULL, it is warning you the same as if you wrote $v = 'some_name_you_never_assigned_to

Re: [PHP-DEV] Array dereferencing of scalars

2015-06-10 Thread Yasuo Ohgaki
Hi all, On Thu, Jun 11, 2015 at 7:22 AM, Yasuo Ohgaki wrote: > I agree that NULL is debatable. In PHP, NULL is treated as 0/false by its > context. > It's simpler if we get rid of the behavior altogether. IMO. > If PHP should return NULL always against NULL variables, we may be better to recons

Re: [PHP-DEV] Array dereferencing of scalars

2015-06-10 Thread Christoph Becker
Yasuo Ohgaki wrote: > On Wed, Jun 10, 2015 at 5:30 PM, Nikita Popov wrote: > >> On Wed, Jun 10, 2015 at 8:53 AM, Stanislav Malyshev >> wrote: >> >>> $foo = 42; $foo['bar']; // => NULL $v = NULL; $v[0][1][2][3][4][5][6][7][8][9]; // NULL this code is semantical

Re: [PHP-DEV] Array dereferencing of scalars

2015-06-10 Thread Yasuo Ohgaki
Hi Stas and Nikita, On Wed, Jun 10, 2015 at 5:30 PM, Nikita Popov wrote: > On Wed, Jun 10, 2015 at 8:53 AM, Stanislav Malyshev > wrote: > >> Hi! >> >> > > > $foo = 42; >> > $foo['bar']; // => NULL >> > $v = NULL; >> > $v[0][1][2][3][4][5][6][7][8][9]; // NULL >> > >> > this code is semanti

Re: [PHP-DEV] Array dereferencing of scalars

2015-06-10 Thread AllenJB
On , Nikita Popov wrote: On Wed, Jun 10, 2015 at 8:53 AM, Stanislav Malyshev wrote: Hi! >$foo = 42; > $foo['bar']; // => NULL > $v = NULL; > $v[0][1][2][3][4][5][6][7][8][9]; // NULL > > this code is semantically wrong and I would like to have error/exception > for such > erroneous co

Re: [PHP-DEV] Array dereferencing of scalars

2015-06-10 Thread Nikita Popov
On Wed, Jun 10, 2015 at 8:53 AM, Stanislav Malyshev wrote: > Hi! > > > > $foo = 42; > > $foo['bar']; // => NULL > > $v = NULL; > > $v[0][1][2][3][4][5][6][7][8][9]; // NULL > > > > this code is semantically wrong and I would like to have error/exception > > for such > > erroneous codes. It'

Re: [PHP-DEV] Array dereferencing of scalars

2015-06-09 Thread Stanislav Malyshev
Hi! >$foo = 42; > $foo['bar']; // => NULL > $v = NULL; > $v[0][1][2][3][4][5][6][7][8][9]; // NULL > > this code is semantically wrong and I would like to have error/exception > for such > erroneous codes. It's inconsistent with array object, too. Why it's wrong? You try to get that's s

Re: [PHP-DEV] Array dereferencing of scalars

2015-06-09 Thread Christoph Becker
Rowan Collins wrote: > Christoph Becker wrote on 09/06/2015 14:09: >> I wonder where these coercion rules are described. The manual has a >> section about "Converting to array"[1] which actually describes casting, >> and is obviously not what is happening when the subscript operator (as >> the la

Re: [PHP-DEV] Array dereferencing of scalars

2015-06-09 Thread Rowan Collins
Christoph Becker wrote on 09/06/2015 14:09: I wonder where these coercion rules are described. The manual has a section about "Converting to array"[1] which actually describes casting, and is obviously not what is happening when the subscript operator (as the langspec calls it[2]) is applied to

Re: [PHP-DEV] Array dereferencing of scalars

2015-06-09 Thread Christoph Becker
Rowan Collins wrote: > Yasuo Ohgaki wrote on 09/06/2015 11:44: >> $v = NULL; >> $v[0][1][2][3][4][5][6][7][8][9]; // NULL >> >> this code is semantically wrong and I would like to have error/exception >> for such >> erroneous codes. > > PHP considers an uninitialised variable to have the valu

Re: [PHP-DEV] Array dereferencing of scalars

2015-06-09 Thread Rowan Collins
Christoph Becker wrote on 09/06/2015 13:35: Current behavior: foo->bar; ?> Notice: Trying to get property of non-object in %s on line %d Notice: Trying to get property of non-object in %s on line %d So trying to access a property on NULL gives a notice, but trying to access an eleme

Re: [PHP-DEV] Array dereferencing of scalars

2015-06-09 Thread Rowan Collins
Christoph Becker wrote on 08/06/2015 22:11: The behavior of dereferencing scalars as if they were arrays or strings is arguable: NULL A few things to note here: - accessing a *numeric* offset of a *string* is valid (selects a single character) - accessing a *string* offset of another str

Re: [PHP-DEV] Array dereferencing of scalars

2015-06-09 Thread Christoph Becker
Matt Wilmas wrote: > Forgetting the NULL case for a sec... With: > > $v = []; > $v[0][1][2][3][4][5][6][7][8][9]; > > How/why are we going from 1 Notice to 10?! > > With: > > unset($v); > $v[0]; > > Why from 1 Notice about the undefined variable, to 2? That's totally > new, and it really do

Re: [PHP-DEV] Array dereferencing of scalars

2015-06-09 Thread Rowan Collins
Yasuo Ohgaki wrote on 09/06/2015 11:44: $v = NULL; $v[0][1][2][3][4][5][6][7][8][9]; // NULL this code is semantically wrong and I would like to have error/exception for such erroneous codes. PHP considers an uninitialised variable to have the value NULL, and a NULL value to be coercable

Re: [PHP-DEV] Array dereferencing of scalars

2015-06-09 Thread Matt Wilmas
Hi all, - Original Message - From: "Christoph Becker" Sent: Tuesday, June 09, 2015 Yasuo Ohgaki wrote: I fully agree that current behavior could be used meaningful ways. However, NULL $v = NULL; $v[0][1][2][3][4][5][6][7][8][9]; // NULL this code is semantically wrong and I wou

Re: [PHP-DEV] Array dereferencing of scalars

2015-06-09 Thread Christoph Becker
Yasuo Ohgaki wrote: > I fully agree that current behavior could be used meaningful ways. However, > >$foo = 42; > $foo['bar']; // => NULL > $v = NULL; > $v[0][1][2][3][4][5][6][7][8][9]; // NULL > > this code is semantically wrong and I would like to have error/exception > for such > erro

Re: [PHP-DEV] Array dereferencing of scalars

2015-06-09 Thread Yasuo Ohgaki
Hi Matt, On Tue, Jun 9, 2015 at 7:04 PM, Matt Wilmas wrote: > Hi all, > > > - Original Message - > From: "Yasuo Ohgaki" > Sent: Tuesday, June 09, 2015 > > Hi all, >> >> On Tue, Jun 9, 2015 at 6:21 AM, Stanislav Malyshev >> wrote: >> >> > Would throwing a notice or a warning on array d

Re: [PHP-DEV] Array dereferencing of scalars

2015-06-09 Thread Matt Wilmas
Hi all, - Original Message - From: "Yasuo Ohgaki" Sent: Tuesday, June 09, 2015 Hi all, On Tue, Jun 9, 2015 at 6:21 AM, Stanislav Malyshev wrote: > Would throwing a notice or a warning on array deferencing scalars > be acceptable for PHP 7.0, or does this need an RFC? I think this d

Re: [PHP-DEV] Array dereferencing of scalars

2015-06-09 Thread Yasuo Ohgaki
Hi all, On Tue, Jun 9, 2015 at 6:21 AM, Stanislav Malyshev wrote: > > Would throwing a notice or a warning on array deferencing scalars > > be acceptable for PHP 7.0, or does this need an RFC? > > I think this does need an RFC, and for 7.0, pretty much no new language > changes are acceptable an

Re: [PHP-DEV] Array dereferencing of scalars

2015-06-08 Thread Stanislav Malyshev
Hi! > Would throwing a notice or a warning on array deferencing scalars > be acceptable for PHP 7.0, or does this need an RFC? I think this does need an RFC, and for 7.0, pretty much no new language changes are acceptable anymore, since we're past the timeframe. -- Stas Malyshev smalys...@gmail.

[PHP-DEV] Array dereferencing of scalars

2015-06-08 Thread Christoph Becker
The behavior of dereferencing scalars as if they were arrays or strings is arguable: NULL This happens without notice or warning, whereas the array dereferencing of objects results in a fatal error: https://bugs.php.net/bug.php?id=54556> [2] [3]

  1   2   >