Hey all,
I'm looking to get feedback on a RFC I want to propose.
PHP RFC: Addition of the 'struct' data type.
Introduction:
PHP has many data types, but does not offer something that is the
equivalent to the C struct data type.
The purpose of this RFC is to propose a data type of 'struct', w
On Thu, Mar 14, 2019, at 3:41 PM, Theodore Brown wrote:
> > As a small update, I've implemented a proof of concept that uses the ($x)
> > ==> $x * $multiplier syntax (or $x ==> $x * $multiplier for short) in
> > https://github.com/php/php-src/pull/3945. As mentioned in the RFC, this
> > requires s
On 13-03-19 23:30, Rowan Collins wrote:
> At risk of complicating things further, might the solution to that be to
> have a shorter syntax for iterator_to_array in general?
>
> It's a shame array-casts are defined for arbitrary objects, else we
> could have (array)$iterator - and therefore (array)
On 14-03-19 04:21, Larry Garfield wrote:
> To the question of having both a generator and array version, I would have to
> say no. As noted in the RFC, most cases where you'd want to use a
> comprehension are not places where you'd be feeding the result into an array
> function. On the off cha
Hi,
The plan is to start rolling this out somewhere in the next two weeks,
pending solving the problem of not 404ing the xx.php.net URLs. What I
would like to do is, to 301 redirect these to the canonical URLs so that
search indexes etc can get updated over time. But, I don't quite know
where
On Thu, March 14, 2019 10:41 AM Nikita Popov wrote:
> On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov wrote:
>
> > Hi internals,
> >
> > Motivated by the recent list comprehensions RFC, I think it's time we took
> > another look at short closures:
> >
> > https://wiki.php.net/rfc/arrow_functions_v
I note that there was some recent discussion about fixing DOMNameSpaceNode
on this list. I'd like to bring up a (perhaps) related issue: the
dom_reconcile_ns() function which is called whenever a new namespaced node
(for example, created with Document#createElementNS) is inserted into the
tree. d
I'm floating an idea for an RFC here.
I'm working on the wikimedia/remex-html library for high-performance
PHP-native HTML5 parsing. When creating a high-performance lexer, it is
worthwhile to try to reduce the number of string copies made. You can
generally perform matches using offsets into yo
Hello,
A timeline would be nice and information on if locally mirroring it (on an
internal hostname) will still be possible.
Also it would be nice to know if you will be contacting the rsync mirror
maintainers and what you want to do with them.
I've said before and I will repeat again: let me
On Thu, 14 Mar 2019 at 18:20, Josh Di Fabio wrote:
> On Thu, Mar 14, 2019 at 3:49 PM Rowan Collins
> wrote:
> >
> > Is it really that important to save two key strokes per closure?
> >
>
> I'd say that the (probably overwhelming) majority of arrow functions
> have a single parameter and, in thos
On Thu, Mar 14, 2019 at 3:49 PM Rowan Collins wrote:
>
> Is it really that important to save two key strokes per closure?
>
I'd say that the (probably overwhelming) majority of arrow functions
have a single parameter and, in those cases, the JS syntax saves four
characters, ignoring whitespace. A
On Thu, 14 Mar 2019 at 15:10, Benjamin Morel
wrote:
> The problem, as I understand it, is not avoiding ambiguity, it's avoiding
>> lookahead.
>
>
> You're right, I was only thinking about resolving the ambiguity with array
> keys. It's too bad if the parser implementation considerations take
> pr
On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov wrote:
> Hi internals,
>
> Motivated by the recent list comprehensions RFC, I think it's time we took
> another look at short closures:
>
> https://wiki.php.net/rfc/arrow_functions_v2
>
> This is based on a previous (withdrawn) proposal by Levi & Bob.
Em qui, 14 de mar de 2019 às 03:17, Rowan Collins
escreveu:
> I don't think this helps, because you can put brackets around any
> expression, for precedence, and any expression can appear on the left of an
> array literal:
>
> $foo = [ ($bar + 1) * 2 => $baz ];
>
> So the following, while redunda
Any update on this? One commonly requested feature on the downloads
page can be implemented once the mirrors are gone, which is to
directly link to to the file (instead of a Choose a Mirror page).
On Wed, Feb 27, 2019 at 9:28 AM Derick Rethans wrote:
>
> Hi!
>
> The PHP.net website has in the las
>
> The problem, as I understand it, is not avoiding ambiguity, it's avoiding
> lookahead.
You're right, I was only thinking about resolving the ambiguity with array
keys. It's too bad if the parser implementation considerations take
precedence over the purity of the language, but I can understan
On Thu, 14 Mar 2019 at 14:12, Benjamin Morel
wrote:
> This makes me thinking, has this syntax been considered?
>
> ($x) => { $x * $y }
>
> Nested:
>
> ($x) => { ($y) => { $x * $y } }
>
Wouldn't this have all the same parser problems as the RFC discusses?
The problem, as I understand it, is not
This makes me thinking, has this syntax been considered?
($x) => { $x * $y }
Nested:
($x) => { ($y) => { $x * $y } }
AFAICS, we don't need the brackets around the whole expression, as this
should be parsable without any ambiguity; and the syntax would be closer to
that of JavaScript.
On Thu,
Hi,
it's nice to see this going on again :)
while reading the rfc I was wondering, why do we need the "static" keyword,
couldn't static function be detected automatically ?
I guess this apply to the existing closure syntax as well so to get more on
this topic I'll share my preferences on th
On 13 March 2019 15:56:40 GMT+00:00, Nikita Popov wrote:
>Motivated by the recent list comprehensions RFC, I think it's time we
>took
>another look at short closures:
>
>https://wiki.php.net/rfc/arrow_functions_v2
Hi Nikita,
Thanks for reviving this. I think the RFC does a great job of
justifyin
On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov wrote:
> Hi internals,
>
> Motivated by the recent list comprehensions RFC, I think it's time we took
> another look at short closures:
>
> https://wiki.php.net/rfc/arrow_functions_v2
>
> This is based on a previous (withdrawn) proposal by Levi & Bob.
czw., 14 mar 2019, 04:22 użytkownik Larry Garfield
napisał:
> On Wed, Mar 13, 2019, at 6:30 PM, Rowan Collins wrote:
> > On 13/03/2019 21:10, Dik Takken wrote:
> > > So in practice, I expect that
> > > using comprehensions as proposed in the new RFC will also require doing
> > > a lot of iterator
22 matches
Mail list logo
