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

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

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

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

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

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

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

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

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

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

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] Re: Allowing $a = foo($a) to operate in-place (was Re: [PHP-DEV] Array spread append)

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)

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

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

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

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

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

> 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

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

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

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

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

> > > * 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

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

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

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

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

> 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

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]

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

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

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

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

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

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

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

Re: [PHP-DEV] Array max size

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

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

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

*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

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

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

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

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

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

Re: [PHP-DEV] array coalesce operator concept

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

"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-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-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 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

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

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

> 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

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

> 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

> 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

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

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

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

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

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

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

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

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

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

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

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?

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.

Re: [PHP-DEV] Array dereferencing of scalars

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

RE: [PHP-DEV] Array decomposition, more than list()

would be really incredible for PHP as well. I see on that document it does not talk about a complex destructuring such as I've described above. My email here was to find if this would garner any interest from the PHP community. > -Original Message- > From: Ivan Enderl

Re: [PHP-DEV] Array decomposition, more than list()

Hi Clint, On 13/05/12 18:41, Clint Priest wrote: I've been using array decomposition in other languages such as Javascript recently and find it very useful. I did not find any conversation about it in the archives, has this topic been discussed/vetted/shot down already? Example use case: Ind

Re: [PHP-DEV] Array dereferencing using alternative array syntax

On Mon, Oct 10, 2011 at 12:02 PM, Pierre Joye wrote: > On Mon, Oct 10, 2011 at 11:55 AM, Nikita Popov > wrote: > >> Imho it should be supported regardless of whether we want to remove it >> or not - for the sake of consistency. > > If we ever want to have a consistent syntax, then no, we should n

Re: [PHP-DEV] Array dereferencing using alternative array syntax

hi, On Mon, Oct 10, 2011 at 11:55 AM, Nikita Popov wrote: > Imho it should be supported regardless of whether we want to remove it > or not - for the sake of consistency. If we ever want to have a consistent syntax, then no, we should not add it and only support the consistent syntax in new add

Re: [PHP-DEV] Array dereferencing using alternative array syntax

On Mon, Oct 10, 2011 at 11:03 AM, Ferenc Kovacs wrote: > the alternate syntax has a rough past (if I remember correctly, [] was > mentioned to be deprecated, then with 5.3 the preference was switched: > [] is the preferred way now, and {} got almost deprecated), so if we > plan to support the {} s

Re: [PHP-DEV] Array dereferencing using alternative array syntax

On Mon, Oct 10, 2011 at 1:30 AM, Peter Cowburn wrote: > Hi Nikita, > > On 9 October 2011 18:14, Nikita Popov wrote: >> Hi list! >> >> PHP 5.4 added array dereferencing support (e.g. `func()[1]`), but the >> grammar seems to lack support for dereferencing using the alternative >> array access synt

Re: [PHP-DEV] Array dereferencing using alternative array syntax

Hi Nikita, On 9 October 2011 18:14, Nikita Popov wrote: > Hi list! > > PHP 5.4 added array dereferencing support (e.g. `func()[1]`), but the > grammar seems to lack support for dereferencing using the alternative > array access syntax (e.g. `func(){1}`). Was this done on purpose or > was it just

Re: [PHP-DEV] Array access for UTF-strings (Was: PHP 6 as we know it suddenly died?)

On Sat, Mar 13, 2010 at 14:59, Keryx Web wrote: > To all: > > I note that my question is still unanswered. > Ask again in a year. We simply do not know. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Array access for UTF-strings (Was: PHP 6 as we know it suddenly died?)

2010-03-12 18:36, Tomas Kuliavas skrev: Keryx Web rašė: 2. If so, what will happen to array access in strings that are de facto Unicode? Will the more clunky mb_substr() be the only option? What will happen to array access in unicode strings, if code wants to access them in bytes? Will some ba

Re: [PHP-DEV] array position isfirst / islast / valid ?

Hello On 2.1.2010 21:36, Kalle Sommer Nielsen wrote: How about just array_pos() if any. The remaining functions can easily be implemented in userland like: function array_pos_isfirst(Array&$array) { return array_pos($array) == 0; } function array_pos_islast(Array&$array) { return array_pos

  1   2   >