On Wed, August 7, 2024 at 08:27 Derick Rethans wrote:
> On 7 August 2024 14:30:24 BST, Theodore Brown wrote:
>> I really appreciate RFCs like this which not only make the language more
>> consistent for userland developers, but also simplify PHP's internal
>> implemen
On Tue, July 30, 2024 at 03:49 G. P. Banyard wrote:
> Hello Internals,
>
> I have just opened the vote for the "Transform exit() from a language
> construct into a standard function" RFC:
> https://wiki.php.net/rfc/exit-as-function
>
> The vote will last for two weeks until the 13th of August 202
On Fri, July 26, 2024 at 12:25 Larry Garfield wrote:
> Voting for Asymmetric Visibility is now open.
>
> https://wiki.php.net/rfc/asymmetric-visibility-v2
Hi Larry and Ilija,
Thank you for all your work on this RFC!
One part that doesn't make sense to me is this sentence near the end in the
"R
On Thu, Sep. 21, 2023 at 12:26 PM Tim Düsterhus wrote:
> I just opened the vote for the "Increasing the default BCrypt cost" RFC.
> The RFC contains a two votes, one primary vote that requires a 2/3
> majority to pass and a secondary vote deciding on the new costs with a
> simple majority. Voting
On Thu June 29, 2023 at 11:51 AM Theodore Brown wrote:
> On Tue, June 27, 2023, 6:33 Rowan Tommins wrote:
> > On 27/06/2023 02:25, Theodore Brown wrote:
> > > Currently the following code returns only the array keys that loosely
> > > equal null:
> > >
On Tue, June 27, 2023, 6:33 Rowan Tommins wrote:
> On 27/06/2023 02:25, Theodore Brown wrote:
> > Currently the following code returns only the array keys that loosely equal
> > null:
> >
> > array_keys($array, null)
> >
> > If the function is changed t
On Mon, June 26, 2023, at 14:43 Nikita Popov wrote:
> On Mon, Jun 26, 2023, at 20:22, Ben Ramsey wrote:
> >
> > I voted “no” on `array_keys()` because I do not see these as two different
> > function signatures. To me, the single signature should look like this:
> >
> > function array_keys(arr
On Fri, Dec 16, 2022 at 5:09 PM Derick Rethans wrote:
>On 16 December 2022 21:34:16 GMT, Theodore Brown
>wrote:
>>On Thu, Dec 15, 2022 at 8:27 AM Derick Rethans wrote:
>>
>>> Hi,
>>>
>>> I've just opened the vote for "More Appropriate Dat
On Thu, Dec 15, 2022 at 8:27 AM Derick Rethans wrote:
> Hi,
>
> I've just opened the vote for "More Appropriate Date/Time Exceptions".
> It runs until December 31st, 24:00 UTC.
>
> You can vote at:
> https://wiki.php.net/rfc/datetime-exceptions#voting
Hi Derick,
Thank you for your work on thi
On Fri, Mar 18, 2022 at 09:02 Chase Peeler wrote:
> On Fri, Mar 18, 2022 at 12:49 AM Theodore Brown
> wrote:
> >
> > Personally I'm really looking forward to having this functionality.
> > Just a couple days ago I wanted to call a function in an interpolated
ying to have to wrap the function in a
closure in order to use it.
If this RFC is accepted I'd be able to replace code like this:
$name = "Theodore Brown";
$strlen = fn(string $string): int => strlen($string);
echo "{$name} has a length of {$strlen
On Friday, July 23, 2021 at 4:58 AM Nicolas Grekas
wrote:
> Hi everyone,
>
> as proposed by Nikita and Joe, I'm submitting this late RFC for your
> consideration for inclusion in PHP 8.1. Intersection types as currently
> accepted are not nullable. This RFC proposes to make them so.
>
> I wrote
On Tue, Mar 30, 2021 at 5:24 PM Matthew Brown wrote:
> On Tue, 30 Mar 2021 at 12:55, Theodore Brown wrote:
>
> > On Tue, Mar 30, 2021 at 10:06 AM Matthew Brown
> > wrote:
> >
> > > Hey everyone!
> > >
> > > The vote for adding noretur
On Tue, Mar 30, 2021 at 10:06 AM Matthew Brown wrote:
> Hey everyone!
>
> The vote for adding noreturn is now open:
>
> https://wiki.php.net/rfc/noreturn_type
>
> Voting will run through April 13th
Hi Matt and Ondrej,
Thanks for your work on this RFC. I voted for `never` as the type name
bec
On Sun, Jan 3, 2021 at 8:56 PM Larry Garfield wrote:
> On Sun, Jan 3, 2021, at 12:17 PM, tyson andre wrote:
> > > I've created the RFC https://wiki.php.net/rfc/is_list
> > >
> > > This adds a new function `is_list(mixed $value): bool` that will
> > > return true if the type of $value is array and
On Sat, Oct 31, 2020, at 5:06 AM, Rowan Tommins wrote:
> > This would be an artificial limitation on attributes to patch
> > over the inherent inconsistency of the grouped syntax for nested
> > attributes.
>
> There is no artificial limitation; there is a binary choice: does
> #[Foo] represent an
On Fri, Oct 30, 2020 at 2:28 PM Rowan Tommins wrote:
> On 30/10/2020 18:47, Theodore Brown wrote:
> > While passing all nested attributes as an array would at least enable
> > consistent semantics, it has the notable disadvantage of preventing
> > some use cases from bei
Hi Rowan and Nicolas (and internals),
On Wed, Oct 28, 2020 at 12:57 PM Rowan Tommins wrote:
> On 28/10/2020 16:58, Nicolas Grekas wrote:
> > about why we'd need nested attributes, here is a discussion about
> > nested validation constraints:
> > https://github.com/symfony/symfony/issues/38503
>
On Tue, Oct 20, 2020 at 10:13 AM Rowan Tommins wrote:
> On Mon, 19 Oct 2020 at 16:17, Theodore Brown wrote:
>
> >
> > In theory nested attributes could be supported in the same way with
> > the `#[]` syntax, but it's more verbose and I think less intuitive
> &
On Mon, Oct 5, 2020 at 9:24 AM Nicolas Grekas wrote:
>> I'm wondering if the syntax that allows for several attributes is
>> really future-proof when considering nested attributes:
>>
>>
>> *1.*
>> #[foo]
>> #[bar]
>>
>> VS
>>
>> *2.*
>> #[foo, bar]
>>
>> Add nested attributes to the mix, here ar
Hi internals,
Since the #[] attribute syntax is currently winning the vote, [1]
it makes me wonder if the use of comments starting with # should be
deprecated.
Otherwise it seems like we could be setting ourselves up for long-term
confusion between attributes and comments, and also inconsistency
On Thu, Aug 20, 2020 at 2:13 AM
Côme Chilliet wrote:
> Le Wed, 19 Aug 2020 21:11:29 +,
> Theodore Brown a écrit :
> > In case anyone wants to view the in-progress STV vote results, I took
> > the same script I made for the Shorter Attribute Syntax RFC and made
> > i
On Wed, Aug 19, 2020 at 11:09 AM Benjamin Eberlei wrote:
> I wanted to clarify that this is the **restarted* vote on Shorter
> Attribute Syntax Change, that means all votes cast between August
> 11th and 15th have been reset.
In case anyone wants to view the in-progress STV vote results, I took
Hi Benjamin,
Thank you again for putting in the effort to update the RFC and
address most of the arguments brought up on list.
I would encourage everyone to read through the complete RFC before
voting, particularly the sections on BC breaks and forward
compatibility pros/cons. Top link:
https://w
On Tue, Aug 18, 2020 at 1:00 PM Benjamin Eberlei wrote:
> https://wiki.php.net/rfc/shorter_attribute_syntax_change
>
> I have updated the RFC one last time with as much of the feedback
> as possible:
>
> - a section about comparing to complexity of type definitions
> - removal of the machine re
On Mon, Aug 17, 2020 at 10:21 AM Benjamin Eberlei wrote:
> On Mon, Aug 17, 2020 at 5:14 PM Theodore Brown wrote:
> > On Mon, Aug 17, 2020 at 8:07 AM Theodore Brown wrote:
> > > On Mon, Aug 17, 2020 at 7:11 AM Benjamin Eberlei wrote:
> > > > On Mon, Aug 17, 2020 a
On Mon, Aug 17, 2020 at 8:07 AM Theodore Brown wrote:
> On Mon, Aug 17, 2020 at 7:11 AM Benjamin Eberlei wrote:
> > On Mon, Aug 17, 2020 at 3:06 AM Theodore Brown
> > wrote:
> > > ## Potential Future Benefits of Enclosed Delimiter Syntax?
> > >
> > &g
On Mon, Aug 17, 2020 at 7:11 AM Benjamin Eberlei wrote:
> On Mon, Aug 17, 2020 at 3:06 AM Theodore Brown wrote:
> > However, ending delimiters in PHP have little to do with how "complex"
> > a syntax construct is (which is a rather loose definition, anyway).
>
On Sun, Aug 16, 2020 at 4:36 AM Benjamin Eberlei wrote:
> We have updated the RFC with all (hopefully) of the feedback from
> this discussion:
>
> https://wiki.php.net/rfc/shorter_attribute_syntax_change
>
> Most notable changes are:
> - A new section with several subsections on the benefits of
On Fri, Aug 14, 2020 at 2:23 PM Derick Rethans wrote:
> On Fri, 14 Aug 2020, Sara Golemon wrote:
>
> > > Derick and Benjamin (and Sara), are these requests reasonable? If
> > > the RFC follows the discussion period rule and contains all the
> > > relevant information, I will be much more confide
On Fri, Aug 14, 2020 at 9:48 AM Sara Golemon wrote:
> On Fri, Aug 14, 2020 at 7:22 AM Theodore Brown wrote:
> > I was very surprised that it went to vote less than six days after
> > the discussion period started, right after the weekend no less,
> > before I had a chance
On Fri, Aug 14, 2020 at 9:16 AM Benjamin Eberlei wrote:
> On Fri, Aug 14, 2020 at 2:22 PM Theodore Brown wrote:
> > There's certainly been a lot of discussion in general about
> > attributes. However, there was not a reasonable opportunity to either
> > discuss the
On Thu, Aug 13, 2020 at 8:41 PM Levi Morrison
wrote:
> > So, a week+ early, then? Surely that means the current vote null
> > and void, to be reset entirely following a proper discussion period
> > -- one without concurrent voting.
>
> I just want to make sure I understand: there are people who
On Thu, Aug 13, 2020 at 8:47 AM Andreas Leathley wrote:
> On 13.08.20 15:17, Theodore Brown wrote:
> > The discussion thread you're referencing did not announce an RFC. Per
> > the voting rules, a "Proposal is formally initiated by creating an
> > RFC on PHP wik
On Thu, Aug 13, 2020 at 3:13 AM Michał Marcin Brzuchalski
wrote:
> Hi Theodore,
>
> śr., 12 sie 2020 o 18:36 Theodore Brown napisał(a):
> > On Wed, Aug 12, 2020 at 10:25 AM Sara Golemon wrote:
> >
> > > On Wed, Aug 12, 2020 at 9:48 AM Theodore Brown wrote:
>
On Wed, Aug 12, 2020 at 10:25 AM Sara Golemon wrote:
> On Wed, Aug 12, 2020 at 9:48 AM Theodore Brown wrote:
>
> > It has just come to my attention that this RFC was rushed to vote
> > after less than the minimum two week period required after it was
> > brought
On Mon, Aug 10, 2020 at 3:41 AM Derick Rethans wrote:
>I've just opened the vote to make sure we don't make a terrible mistake
> with using the @@ syntax for attributes:
>
> https://wiki.php.net/rfc/shorter_attribute_syntax_change#voting
>
> The vote ends August 23, 24:00 UTC.
It has just come t
On Tue, Aug 11, 2020 at 11:36 AM Rowan Tommins wrote:
> On Tue, 11 Aug 2020 at 17:07, Theodore Brown wrote:
>
> > > > fact that the @@ syntax makes attributes easier to grep for.
> >
> > This can be a simple Yes or No. With @@ or @: you can type those
> > sy
On Tue, Aug 11, 2020 at 10:39 AM Rowan Tommins wrote:
> On Tue, 11 Aug 2020 at 16:31, Theodore Brown wrote:
>
> > Anyway, please do add easy typeability to the matrix
>
> How would you measure "easy typability"? On what keyboard layout?
> Would you write &quo
On Tue, Aug 11, 2020 at 8:37 AM Derick Rethans wrote:
> On Tue, 11 Aug 2020, Theodore Brown wrote:
>
> > A second downside of @[] that doesn't appear to have been discussed
> > yet is typability. On my keyboard, it requires four different keys on
> > different s
On Tue, Aug 11, 2020 at 7:26 AM Chris Riley wrote:
> On Tue, 11 Aug 2020 at 13:21, Derick Rethans wrote:
>
> > On Tue, 11 Aug 2020, Chris Riley wrote:
> >
> > > Quick question.
> > >
> > > What is the expected behaviour of:
> > >
> > > @[Bar()];
> > > class Foo {}
> >
> > That will error out in
On Mon, Aug 10, 2020 at 3:41 AM Derick Rethans wrote:
> I've just opened the vote to make sure we don't make a terrible mistake
> with using the @@ syntax for attributes:
>
> https://wiki.php.net/rfc/shorter_attribute_syntax_change#voting
>
> The first vote is a vote to say that you have an opi
On Fri, Aug 7, 2020 at 6:03 AM Derick Rethans wrote:
> On Fri, 7 Aug 2020, Theodore Brown wrote:
>
> > Even if we assume the implementation is only about 30 lines, it's
> > still extra complexity that I don't understand the benefit of. I
> > sincerely would li
On Fri, Aug 7, 2020 at 3:32 AM Benjamin Eberlei wrote:
> On Fri, Aug 7, 2020 at 2:24 AM Theodore Brown wrote:
> > On Thu, Aug 6, 2020 at 12:30 PM Benas IML >
> > wrote:
> >
> > > Hey Theodore,
> > >
> > > On Thu, Aug 6, 2020, 8:05 PM Theod
On Thu, Aug 6, 2020 at 12:30 PM Benas IML wrote:
> Hey Theodore,
>
> On Thu, Aug 6, 2020, 8:05 PM Theodore Brown wrote:
>
> > While none of our syntax options are perfect, I believe @@ has the
> > best long-term tradeoffs because:
> >
> > - It doesn&#x
On Thu, Aug 6, 2020 at 5:24 AM Benas IML wrote:
> On Thu, 6 Aug 2020 at 11:45, Rowan Tommins wrote:
>
> > On Thu, 6 Aug 2020 at 09:12, Benas IML wrote:
> >
> > > But by sacrificing a few very old codebases (that still use `#` not `//`)
> >
> > Do you have some basis for # only being used by "v
On Wed, Aug 5, 2020 at 7:20 AM Benjamin Eberlei wrote:
> On Tue, Aug 4, 2020 at 6:37 PM Theodore Brown wrote:
> > On Tue, Aug 4, 2020 at 8:45 AM Derick Rethans wrote:
> >
> > > Out of Banjamin's suggestion[1], I've updated the Shorter Attribute
> > >
On Tue, Aug 4, 2020 at 8:45 AM Derick Rethans wrote:
> Out of Banjamin's suggestion[1], I've updated the Shorter Attribute
> Syntax Change RFC to reflect that process:
>
> https://wiki.php.net/rfc/shorter_attribute_syntax_change
>
> Patches and comments welcome.
Hi Derick,
I don't agree with
On Sun, Aug 2, 2020 at 4:40 PM Dan Ackroyd wrote:
> Theodore Brown wrote:
> >
> > The Shorter Attribute Syntax RFC explicitly mentioned that the @@
> > syntax would supersede the grouped attributes proposal: [1]
>
> From the RFC:
> >
> > # Unaffected Fun
On Sun, Aug 2, 2020 at 10:06 AM Derick Rethans wrote:
> On Wed, 29 Jul 2020, Benjamin Eberlei wrote:
>
> > Personally I favor #[] myself, but there has been a vote with a
> > substantial participation choosing @@. Overturning this democratic
> > outcome should require **significant** technical a
On Tue, July 28, 2020 at 6:09 PM Mark Randall wrote:
> On 28/07/2020 22:55, Theodore Brown wrote:
> > I appreciate the examples. I think there are good reasons not to
> > implement these kind of extensions, at least in this form. I'll reply
> > to each example below.
&
On Tue, July 28, 2020 at 2:38 PM Mark Randall wrote:
> On 28/07/2020 18:57, Theodore Brown wrote:
> >> Having a closing ] makes it easier to extend Attributes with more syntax
> >
> > This might be a good argument if there were actually a need to extend
> > att
On Tue, July 28, 2020 at 9:46 AM Joe Ferguson wrote:
> Hello Internals,
>
> I've been working with Derick Rethans and others (thanks all!) on a Shorter
> Attribute Syntax Change RFC which outlines reasons why the "#[]" syntax
> would be preferred over the currently agreed upon "@@" syntax for Sh
On Thu, July 23 2020 at 1:26 AM Mark Randall wrote:
> On 23/07/2020 02:00, Sara Golemon wrote:
> > Regards the vote; I don't believe that @@ has been proven unworkable,
> > however if I'm wrong about that, then the second choice selection from the
> > last vote would obviously take precedence.
>
On Wed, July 22 2020 at 7:00 AM Derick Rethans wrote:
> I know we've voted twice on this already, but are we really sure that
> the @@ syntax is a good idea?
>
> - There are lots of grumbles, both on here, room 11, as well as in the
> wider community (https://www.reddit.com/r/PHP/comments/hjpu
On Thu, July 16 2020 at 3:04 AM Nikita Popov wrote:
> While I don't think anyone had plans to mix whitespace, this is
> indicative of a larger issue. While I'm one of the people who voted
> for @@ as my first choice before, I wouldn't do so now (even with
> this RFC accepted). This issue made me
On Tue, July 14 2020 at 10:10 AM Levi Morrison wrote:
> On Mon, Jul 13, 2020 at 11:52 AM Marcio Almada wrote:
> > > I'd like to change the default mode of assertion failures to throw.
> > > The current default is to warn. In my opinion this is a bad strategy:
> > > the engine asserted that someth
On Thu, July 2, 2020 at 4:12 PM Benas IML wrote:
> I have opened the voting for the RFC, let's hope everything is going
> to be smooth :). If you have any other questions, let me know!
>
> RFC: https://wiki.php.net/rfc/make_ctor_ret_void
Hi Benas,
Thanks for your work on this. I'm in favor of
On Thu, July 2 2020 at 8:14 AM Nikita Popov wrote:
> On Thu, Jul 2, 2020 at 2:13 AM Theodore Brown wrote:
> > On Wed, June 17, 2020 at 5:59 PM Theodore Brown wrote:
> >
> > > I've opened voting on the Shorter Attribute Syntax RFC:
> > > https://wik
On Wed, June 17, 2020 at 5:59 PM Theodore Brown wrote:
> I've opened voting on the Shorter Attribute Syntax RFC:
> https://wiki.php.net/rfc/shorter_attribute_syntax
>
> Since all RFCs require a primary vote with a 2/3 majority, there is
> a main vote to approve the secondar
On Mon, June 29, 2020 at 10:13 AM Nikita Popov wrote:
> On Tue, Jun 23, 2020 at 12:10 PM Nikita Popov wrote:
>
> > As we're moving in on feature freeze, I plan to move this proposal forward
> > soonishly.
> >
> > I have update the RFC to drop the syntax as an open question (I haven't
> > seen m
horter Attribute Syntax
On 18.06.2020 01:59, Theodore Brown wrote:
> Hi internals,
>
> I've opened voting on the Shorter Attribute Syntax RFC:
> https://wiki.php.net/rfc/shorter_attribute_syntax
If @@ wins, will a sequence of 3-or-more @ characters forbidden? It is
not state
On Thu, June 18, 2020 at 8:40 AM Mark Randall wrote:
> On 18/06/2020 00:59, Theodore Brown wrote:
> > I've opened voting on the Shorter Attribute Syntax RFC:
> > https://wiki.php.net/rfc/shorter_attribute_syntax
>
> I'd be wary of @@ simply because if we do add
I would like the ability to vote on PHP RFCs.
I worked on two successful RFCs for PHP 7.4 (numeric literal separators and the
curly brace array/string access deprecation), and have also contributed other
bug fixes and improvements to core.
--
PHP Internals - PHP Runtime Development Mailing Lis
On Wed, June 17, 2020 at 7:23 PM Ben Ramsey wrote:
> > On Jun 17, 2020, at 18:59, Theodore Brown wrote:
> >
> > I've opened voting on the Shorter Attribute Syntax RFC:
> > https://wiki.php.net/rfc/shorter_attribute_syntax
> >
> > Since all RFCs require
Hi internals,
I've opened voting on the Shorter Attribute Syntax RFC:
https://wiki.php.net/rfc/shorter_attribute_syntax
Since all RFCs require a primary vote with a 2/3 majority, there is
a main vote to approve the secondary ranked-choice vote.
For the ranked-choice poll, fill in your first thro
On Wed, June 3, 2020 at 6:54 PM Theodore Brown wrote:
> Hi internals,
>
> I discussed the syntax for attributes further with Benjamin, Martin,
> and several other internals developers off-list, and with their
> feedback completed an RFC proposing to use the shorter `@@` synt
On Wed, June 10, 2020 at 3:11 AM Michał Brzuchalski
wrote:
> I just noticed a power of Rusts outer attributes which this syntax
> count follow in a future. Following outer attributes in Rust's we
> could introduce in a future syntax like
>
> #![StrictTypes,Module("my_module"),Opcache(s
Hi Sebastian,
On Wed, June 10, 2020 at 12:37 AM Sebastian Bergmann wrote:
> Am 09.06.2020 um 17:57 schrieb Theodore Brown:
> > That's an interesting argument. After thinking about it more, though,
> > I'm not sure I understand what the benefit would be. The docblock
Hi Benjamin,
On Tue, June 9, 2020 at 6:55 AM Benjamin Eberlei wrote:
> Larry's suggestion about `#[Attr]` makes an important argument about
> allowing to declare attributes in code in PHP 7 in a forward compatible
> way that has not been brought up before.
>
> ```php
> /** @ORM\Entity */
> #[ORM\
On Mon, June 8, 2020 at 1:08 PM Markus Fischer wrote:
> I noticed that my `@` character did bleed/meld almost with the first
> character of the attribute name...wide characters like the `M` almost
> touch the `@`.
Hi Markus,
The first question that comes to my mind is, wouldn't this also be an
On Mon, June 8, 2020 at 10:01 AM Larry Garfield wrote:
> FWIW, I find both alternatives ugly to my eye. So, there's that.
>
> Given that `@` is off the table for obvious reasons, my preference
> would frankly be for Rust's `#[]`, which has the nice side effect
> of being a normal comment in ear
Hi Rowan,
On Sun, June 7, 2020 at 5:32 PM Rowan Tommins wrote:
> On 07/06/2020 19:37, Theodore Brown wrote:
> > Yes, I agree that there's a judgment call to make. Out of curiosity,
> > given these shortcomings of the double-angle-bracket syntax, do you
> > think there
Hi Rowan,
On Sat, June 6, 2020 at 7:06 AM Rowan Tommins wrote:
> The `::` token in the parser is called `T_PAAMAYIM_NEKUDOTAYIM`, and
> personally I find `T_SL` and `T_SR` just as cryptic and irrelevant. The most
> common place I see those token names is when accidentally running code
> with
On Fri, June 5, 2020 at 4:24 AM Nikita Popov wrote:
> On Fri, Jun 5, 2020 at 11:14 AM Nicolas Grekas
> wrote:
>
> >> It's that time of year again. Feature freeze is looming, so it's time to
> >> talk about deprecations!
> >>
> >> https://wiki.php.net/rfc/deprecations_php_8_0
> >
> > Thanks for t
On Thu, June 4, 2020 at 12:19 PM Rowan Tommins wrote:
> Hi Theodore,
Hi Rowan,
Thanks for the feedback. I added replies inline.
> I find the "objective" reasons in this RFC to be greatly exaggerated.
>
> 1. `@@Jit` does not require "half as many characters" as `<>`;
> even for this, which is
On Thu, June 4, 2020 at 3:28 PM Marcio Almada wrote:
> I'd also prefer any attribute syntax without the bracket-like pair
> of tokens. I'm just a bit confused about the RFC itself and the PR
> content at this point.
>
> The RFC is currently proposing `@@MyAttribute()` and the PR
> is currently i
On Thu, June 4, 2020 at 6:55 AM Jordi Boggiano wrote:
> Thanks for the write-up. I didn't feel strongly either way before but
> after reading the RFC I am hoping it passes.
>
> Another fringe benefit is the ability to grep for attributes, @@ does
> not occur anywhere in a couple projects I che
On Thu, June 4, 2020 at 5:39 AM Iván Arias wrote:
> As we are creating new syntax, why not simply use another single
> symbol? Here are some examples:
>
> ```php
> *Deprecated
> %Deprecated
> >Deprecated
> &Deprecated
> function foo() { }
> ```
>
> I'm not 100% sure if all this symbols co
On Thu, June 4, 2020 at 5:37 AM Ilija Tovilo wrote:
>>> Does the PHP parser prevent us from adopting #[attr]? I presume
>>> C#'s [attr] syntax and C++'s [[attr]] are impossible due to
>>> PHP's short array syntax.
>>
>> yes, that would create ambiguity in the parser since `#` (just
>> like `//`
Hi internals,
I discussed the syntax for attributes further with Benjamin, Martin,
and several other internals developers off-list, and with their
feedback completed an RFC proposing to use the shorter `@@` syntax
instead of `<<>>` for attributes in PHP 8.
https://wiki.php.net/rfc/shorter_attribu
On Wed, May 20, 2020 at 12:07 PM Benjamin Eberlei wrote:
> the Attributes RFC was rather large already, so a few things were left
> open or discussions during the vote have made us rethink a things.
>
> https://wiki.php.net/rfc/attribute_amendments
>
> These points are handled by the Amendments R
to have named
arguments which can be used anywhere, including in attributes, vs.
having to implement and learn a new syntax for structs which only works
for that one use case (and may not be easy to migrate to).
Best regards,
Theodore Brown
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Mon, Apr 20, 2020 at 4:18 AM Benjamin Eberlei wrote:
> I have opened the vote on the Attributes v2 RFC. The voting will be
> open until two weeks from now, May 4th 2020, noon UTC.
>
> RFC: https://wiki.php.net/rfc/attributes_v2
It's unfortunate that the RFC doesn't more fully enumerate the
ad
On Fri, Apr 17, 2020 at 12:43 PM Benjamin Eberlei wrote:
> On Fri, Apr 17, 2020 at 6:11 PM Theodore Brown wrote:
>
> > Can you provide an example of an attribute name containing whitespace
> > that would be allowed with the shift left/right tokens but not with the
&
On Fri, Apr 17, 2020 at 5:49 AM Benjamin Eberlei wrote:
> As there has only been minimal new discussion after the last changes to the
> RFC I wanted to give a heads up that I will open the vote on Monday
> afternoon.
>
> If you have further remarks or questions about the RFC, please let me know.
On Tue, Feb 25, 2020 at 9:59 AM Nikita Popov wrote:
> On Thu, Feb 13, 2020 at 10:47 AM Nikita Popov wrote:
>
> > This has been discussed a while ago already, now as a proper proposal:
> > https://wiki.php.net/rfc/token_as_object
> >
> > An open question is whether (at least to start with) PhpTok
On Tue, Jan 28, 2020 at 8:22 PM tyson andre wrote:
> Hi internals,
>
> I've opened the vote on https://wiki.php.net/rfc/use_global_elements
Thank you for working to address the issue of ambiguous function references.
However, I really don't think this is the right approach.
The RFC mentions tw
On Sun, Jan 26, 2020 at 10:25 AM tyson andre wrote:
> https://wiki.php.net/rfc/use_global_elements and the implementation
> has been updated again - the syntax is now
> declare(function_and_const_lookup='global')
> with a literal string instead of a keyword.
> The voting option for whether it w
On Fri, Jan 17, 2020 at 11:59 AM Nikita Popov wrote:
>> I've created https://github.com/php/php-src/pull/5067 to make code like
>>function test($foo = null, $bar) {}
>> throw a warning
>
> I was interested in seeing how prevalent this pattern, is, so I ran
> some analysis on the top 2k compos
On Tue, Oct 8, 2019 at 6:02 AM Reinis Rozitis wrote:
> Not directly related to this RFC but out of curiosity - where does
> this "doing the same thing in multiple ways is confusing" comes from?
> (I mean this as serious question)
>
> I had the impression that programming in essence is all about t
On Mon, Oct 7, 2019 at 2:50 AM Nikita Popov wrote:
> On Fri, Oct 4, 2019 at 5:45 PM Mark Randall wrote:
>
> > Hi Internals,
> >
> > I put forward the following RFC "Deprecate Backtick Operator (V2)" for
> > discussion.
> >
> > https://wiki.php.net/rfc/deprecate-backtick-operator-v2
> >
> > I be
On Wed, Aug 28, 2019 at 4:33 AM Nikita Popov wrote:
> I think it's time to take a look at our existing warnings & notices in the
> engine, and think about whether their current classification is still
> appropriate. Error conditions like "undefined variable" only generating a
> notice is really q
On Tue, Aug 27, 2019 at 5:00 PM Dik Takken wrote:
> It had been quiet on the list since I offered to help out, so I
> completely missed people were already working on this.
>
> To avoid any duplication of work, just assign me a couple of extensions
> that nobody is working on yet and I will see w
Seems good to me.
Short tags have long presented a risk of code leakage and lack of portability,
since they are dependent on an ini setting which not everyone has enabled.
Hopefully this can land in time for PHP 7.4.
From: Nikita Popov
Sent: Monday, June 17, 201
On Mon, July 8, 2019 at 9:10 AM Sara Golemon wrote:
> On Sun, Jul 7, 2019 at 3:45 PM Theodore Brown wrote:
>
> > For those voting against adding these functions, can you clarify why?
>
> Explaining my non-vote. I'm explicitly abstaining as I don't see the
>
On Thu, July 4, 2019 at 9:13 PM Will wrote:
> Hello all,
>
> After 15 days of discussion I have opened up voting on the following
> RFC (https://wiki.php.net/rfc/add_str_begin_and_end_functions).
Thank you for your work on this. I'm surprised that so far the vote
is so controversial, with 8 vot
On Thu, July 4, 2019 at 9:13 PM Will wrote:
> After 15 days of discussion I have opened up voting on the following RFC
> (https://wiki.php.net/rfc/add_str_begin_and_end_functions) .
>
> You can access the voting page here:
> https://wiki.php.net/rfc/add_str_begin_and_end_functions/vote
>
> I ha
On Thu, July 4, 2019 at 5:26 PM Björn Larsson wrote:
> Den 2019-07-03 kl. 17:25, skrev Peter Bowyer:
>
> > Thanks for taking the time to push forward this RFC.
> >
> > I found the earlier discussion at https://externals.io/message/104744,
> > which I hadn't seen. Like others, I would have chosen
On Wed, July 3, 2019 at 10:59 AM Nikita Popov wrote:
> On Wed, Jul 3, 2019 at 4:41 PM Levi Morrison wrote:
>
> > Was any analysis of usage done for top open source projects? I support
> > this direction, but would prefer to know its current impact before
> > voting.
>
>
> I checked top 2k pro
1 - 100 of 150 matches
Mail list logo
