Miscellaneous thoughts on this:
- Working to have a vote on https://github.com/php/php-src/pull/4886 might be a
good first step, and something I was personally interested in seeing in 8.0-dev.
However, in the event you can't rule out that is_array($listParam) might not
return true in the
On Tue, Apr 21, 2020 at 10:00 PM Matthew Brown
wrote:
> Why "list" and not "vec" or similar? "list" is also a reserved word – I'm
> imagining that you'd construct a list like
>
> $l = list["a", "b", "c"];
>
"List" usually means linked list, "vector" would be much clearer and
consistent with
Hello again,
Andrea Faulds wrote:
Hi,
Matthew Brown wrote:
I imagine such a "list" type would be a subtype of "array" – everywhere
that array was accepted, a list would be also, and it would have the same
copy-on-write behaviour.
IIRC with the modern implementation of arrays in the Zend
>
> Making a special kind of array _value_ that must stay a “list” sounds
> more problematic… I think without automatic casting back and forth from
> regular “arrays” it might play badly with existing code, but then there
> would be no point…
>
Makes sense – then conversion from lists to arrays
Hello!
>
> Before I create an RFC or attempt a reference implementation, is there any
> interest in adding (and then obviously supporting in perpetuity) a list
> type?
>
> The first line of PHP's documentation for "array" states: "An array in PHP
> is actually an ordered map". There are some
Hi Andrea,
Thank you for the suggestions! The wording of the RFC has been changed,
and now it includes a link to the list of countries which use . as a decimal
separator.
Also, I updated the list of functions that change behaviour, even though
there are only two newly added items: implode() and
Hi,
Matthew Brown wrote:
I imagine such a "list" type would be a subtype of "array" – everywhere
that array was accepted, a list would be also, and it would have the same
copy-on-write behaviour.
IIRC with the modern implementation of arrays in the Zend Engine, you
can check that an array
Before I create an RFC or attempt a reference implementation, is there any
interest in adding (and then obviously supporting in perpetuity) a list
type?
The first line of PHP's documentation for "array" states: "An array in PHP
is actually an ordered map". There are some optimisations that make
Thank you for letting me know! I'm not sure if I can do something though, given
that I'm using ProtonMail.
Best regards,
Benas Seliuginas
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Tuesday, April 21, 2020 7:55 PM, Ben Ramsey wrote:
> > On Apr 21, 2020, at 07:56,
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
> On Apr 21, 2020, at 07:56, Lynn wrote:
>
> Heya,
>
> Fairly off-topic, just so you're aware. This message arrived in my spam
> folder, just like some other messages always do. I get: "pair.com did not
> encrypt this message", which I see come by quite often. A lot of messages
> from Ilija
Hi,
The vote on the PHP 8.0 Release Managers is now closed, and I've run the
STV system to elect our next RMs!
(Spreadsheet is at
https://docs.google.com/spreadsheets/d/1zK425Lu-kYSzsLjL0_U5eLhpr5JYI7vCkZNtPOO_2wE/edit#gid=671237143
if you want to check the numbers)
Votes: 42, Seats: 2,
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.
Replying to a couple of people at once.
On Mon, Apr 20, 2020, at 11:06 PM, Sara Golemon wrote:
> On Mon, Apr 20, 2020 at 9:39 PM Ben Ramsey wrote:
>
> > > On Apr 20, 2020, at 20:38, Larry Garfield
> > wrote:
> > >
> > > I've been commenting on other RFCs enough lately that I should probably
>
Hey internals,
I wanted to ignite a friendly discussion whether PHP should allow typed
callable properties. The problem arises as typed properties RFC did not allow
the callable type [1] due to its context-dependent behaviour. As such, for
improving the language's consistency and adding support
Heya,
Fairly off-topic, just so you're aware. This message arrived in my spam
folder, just like some other messages always do. I get: "pair.com did not
encrypt this message", which I see come by quite often. A lot of messages
from Ilija also ended up in my spam folder and so it did for others.
On Tue, Apr 21, 2020 at 11:10 AM Côme Chilliet
wrote:
>
> Le lundi 20 avril 2020, 09:15:24 CEST Sara Golemon a écrit :
> > use mixed = null|bool|int|float|string|array|object|resource;
> > use scalar = null|bool|int|float|string;
>
> I’m wondering if null should maybe be left out of these, since
On Tue, Apr 21, 2020 at 12:39 PM Peter Bowyer
wrote:
> On Tue, 21 Apr 2020 at 09:15, Peter Cowburn
> wrote:
>
> > I know that I'm "too late" to be making suggestions, but I would like to
> > see
> > a new "@@" operator over the proposed <<...>> or @:.
> >
>
> I support this, and agree with
Hey internals,
I wanted to ignite a friendly discussion whether PHP should allow typed
callable properties. The problem arises as typed properties RFC did not allow
the callable type [1] due to its context-dependent behaviour. As such, for
improving the language's consistency and adding
On Mon, 20 Apr 2020 at 16:17, Larry Garfield wrote:
> I... cannot actually envision what code would actually accept that mess. :-)
var_dump() would be one example. Also caches that can store any
userland value would be another reasonably common use.
The general pattern is when you're handling
Hi internals,
This originally came up in the "Stricter type-checks for arithmetic/bitwise
operators" thread. I would like to add a get_resource_id() function, which
does the same as an (int) $resource cast, just in a more explicit way, that
does not require the reader to be familiar with PHP
On Tue, 21 Apr 2020 at 09:15, Peter Cowburn wrote:
> I know that I'm "too late" to be making suggestions, but I would like to
> see
> a new "@@" operator over the proposed <<...>> or @:.
>
I support this, and agree with Theodore Brown's earlier message (
Le lundi 20 avril 2020, 09:15:24 CEST Sara Golemon a écrit :
> use mixed = null|bool|int|float|string|array|object|resource;
> use scalar = null|bool|int|float|string;
I’m wondering if null should maybe be left out of these, since ?mixed and
?scalar can be used for this?
--
Côme Chilliet
Hey Larry,
This looks good!
One question arises: how do exception traces look like, if they happen
mid-pipe? Is the pipe effectively attaching stack frames to the entire
thing, or is it flattening the trace?
Greets,
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
On
On Tue, Apr 21, 2020 at 3:39 AM Larry Garfield
wrote:
> Hello fine people of Internals!
>
> I've been commenting on other RFCs enough lately that I should probably
> put myself through the wringer, too. I therefore offer this RFC to add a
> function pipe operator, as seen in a number of other
On Mon, 20 Apr 2020 at 22:36, Marco Pivetta wrote:
> Hey Andrea,
>
> On Mon, Apr 20, 2020, 23:25 Andrea Faulds wrote:
>
> > Hi,
> >
> > Benjamin Eberlei wrote:
> > > Hello,
> > >
> > > I have opened the vote on the Attributes v2 RFC. The voting will be
> open
> > > until two weeks from now, May
Hi Benjamin,
pon., 20 kwi 2020 o 14:06 Benjamin Eberlei napisał(a):
> Hi Michał, George,
>
> On Wed, Apr 15, 2020 at 2:29 PM Michał Brzuchalski <
> michal.brzuchal...@gmail.com> wrote:
>
>> Hi internals,
>>
>> I hope you're doing well.
>>
>> I'd like to announce the PHP Namespace in core RFC
Hi Mike
wt., 21 kwi 2020 o 07:29 Mike Schinkel napisał(a):
> I have been wondering for a while why PHP does not officially recognize a
> \PHP namespace.
>
> The inconsistency people have mentioned feels like a fair tradeoff for
> allowing new core classes to be cleanly-named and easier to
28 matches
Mail list logo
