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
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 Date/Tim
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
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
>
ng 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($name)}.";
wi
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
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
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
> &g
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
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:
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
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
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 chan
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 sp
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
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 wiki and
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
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
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 sides
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
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
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 lik
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't
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
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
> > > Syntax C
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
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
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
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
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
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://wiki.php
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 secondary ran
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
E] Shorter 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 stated in
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 validatio
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
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 requir
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
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 `@@` s
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
>
>
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 */
>
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
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
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 are
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
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
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
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
>
> function foo() { }
> ```
>
> I'm not 100% sure if all this symbols could by
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.
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
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
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
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)
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
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
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
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
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
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
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
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,
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
> value in
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
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
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
On Fri, Jun 21, 2019 at 10:20 AM Kalle Sommer Nielsen wrote:
> Nikita and I would like to open the discussion for the RFC:
> "Deprecations for 7.4", this RFC targets a larger set of various
> features targeting for deprecation in 7.4 with the intention of
> removal in PHP 8.0.
>
>
On Thu, May 30, 2019 at 7:50 AM Theodore Brown wrote:
> Voting has now started on the Numeric Literal Separator RFC:
> https://wiki.php.net/rfc/numeric_literal_separator
>
> This feature is widely supported in other languages, and can be very
> helpful for improving c
On Mon, June 3, 2019 at 7:11 AM Andreas Heigl wrote:
> Looks like the stylesheets are loaded from shared.php.net which still
> seems to be on an old certificate. Therefore the styles are not loaded
Styles are loading for me, but I get a certificate error when I try to open
1 - 100 of 146 matches
Mail list logo
