Hi Benjamin,
My PR for #[\Deprecated] attribute was in hibernation for a long while now
> and after some off-list discussion a few weeks ago I have decided to
> revisit it and asked Tim to help me out with the work.
>
> Tim has cleaned up the PR quite a bit and also worked in additional
>
Hi
Le jeu. 4 avr. 2024 à 07:41, youkidearitai a
écrit :
> 2024年4月4日(木) 6:30 Tim Düsterhus :
> >
> > Hi
> >
> > On 4/3/24 10:02, youkidearitai wrote:
> > > Therefore, I think require an RFC, I have written a draft an RFC that
> > > fixes these issues.
> > >
Hi Ilija, Larry,
Heads-up: Larry and I would like to start the vote of the property
> hooks RFC tomorrow:
> https://wiki.php.net/rfc/property-hooks
>
I would make 3 changes to the RFC if I were in charge :
- I'd make $this->propName inside a hook access the parent property via
its hooks
Hi Gina, Máté
Máté Kocsis and myself would like to propose deprecating implicitly
> nullable parameter types.
>
> The RFC is available on the wiki at the following address:
> https://wiki.php.net/rfc/deprecate-implicitly-nullable-types
>
Thanks for the RFC.
I have the same concerns as Larry but
Hi Gina,
I would like to propose an RFC to add the functions
> http_get_last_request_headers() and http_clear_last_request_headers() to
> PHP to replace the magic variable $http_response_header.
>
> Link: https://wiki.php.net/rfc/http-last-response-headers
>
Sorry I missed this RFC.
In
Hello Mate,
I've just closed the votes with the following outcomes:
> - The primary vote for the described approach for converting resources to
> objects was accepted unanimously (30 yes, 0 no)
> - Primary stream resources are going to be migrated in a major version,
> rather in any minor or
> > remove it once it becomes useless.
> >
>
> Do users actually use the $bucket property? I would be surprised if they
> did. They don't
> have to use it as far as I can see.
>
I've used it a few year ago in a stream filtering experiment:
https://github.com/nicolas-grekas/Patchwo
Hi Daniil,
I've opened voting for the final-by-default anonymous classes RFC:
> https://wiki.php.net/rfc/final_by_default_anonymous_classes
>
I voted against the proposal because as I mentioned in the previous thread
on the same topic, this is a backward compatibility break that lacks ground
but
>
>
>>> śr., 3 sty 2024 o 08:12 Nicolas Grekas
>>> napisał(a):
>>>
>>>> Hi Max,
>>>>
>>>> Hi, I'd like to propose a new attribute, #[NotSerializable]. This
>>>> > functionality is already available for interna
> Hi Nicolas,
>
> śr., 3 sty 2024 o 08:12 Nicolas Grekas
> napisał(a):
>
>> Hi Max,
>>
>> Hi, I'd like to propose a new attribute, #[NotSerializable]. This
>> > functionality is already available for internal classes - userspace
>> should
>
Hi Max,
Hi, I'd like to propose a new attribute, #[NotSerializable]. This
> functionality is already available for internal classes - userspace should
> benefit from it, too.
>
> The RFC: https://wiki.php.net/rfc/not_serializable
> Proposed implementation:
Hello Nikita,
> > I've just opened voting for the final anonymous classes RFC @
> > https://wiki.php.net/rfc/final_anonymous_classes.
> >
> > Voting started now, and will run until December 18th 2023, 00:00 GMT.
>
> For the record, I've voted against this proposal because I believe it
> should
Hi Ben
> On Nov 30, 2023, at 02:45, Andreas Heigl wrote:
> >
> > On 30.11.23 09:39, James Titcumb wrote:
> >> On Thu, 30 Nov 2023 at 07:28, Andreas Heigl andr...@heigl.org>> wrote:
> > [...snip...]
> >>I suppose that is actually nothing that an RFC can do as I imagine
> that
> >>
Hi Rowan,
Le jeu. 23 nov. 2023 à 08:56, Rowan Tommins a
écrit :
> On 23 November 2023 01:37:06 GMT, Claude Pache
> wrote:
> >What you describe in the last sentence is what was initially designed and
> implemented by the RFC: https://wiki.php.net/rfc/typed_properties_v2
> (section Overloaded
Hi all,
Ilija and I would like to start a discussion about the following RFC:
> https://wiki.php.net/rfc/pass_scope_to_magic_accessors
>
> When using magic methods to access actual properties, respecting their
> declared visibility is often desired. Yet, accessing the calling scope to
> emulate
Hi Rowan, Larry,
Thanks for the RFC.
I think there is an inaccuracy that needs to be fixed in the after-unset
state : as noted later in the RFC, magic accessors are called after an
unset($this->typedProps). This means the state cannot be described as
identical ("uninitialized') before and after
Hi Daniil and thanks for the RFC.
I would like to submit an RFC and PR to add support for final anonymous
> classes, /or/ make all anonymous classes final by default, with or
> without the possibility to make them non-final.
>
> Here's the URL of the RFC:
>
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 runs 2 weeks until 2023-10-05 17:45 UTC.
>
> Please find
> Instead of passing arguments to __clone(), I wondered about a new
>> __clone_with(array
>> $properties) that could be implemented next to __clone(), with the
>> following behavior:
>>
>>- if only __clone is implemented, same behavior as always
>>- if __clone_with is implemented, __clone
>
> As previously announced on the list, we have just started the vote about
> the annual PHP deprecation RFC.
>
> Link to the RFC: https://wiki.php.net/rfc/deprecations_php_8_3
> Link to the discussion thread: https://externals.io/message/120422
>
> The vote is open until 2023-07-06 12:00:00 UTC.
> Then, among both options, we need to select the one with the best future
> > proofness, and that's definitely the OOP one to me, because it comes with
> > more guarantees (type checks).
>
>
> So are you saying we should deprecate the function-based version
> completely, and not provide any new
Le lun. 19 juin 2023 à 22:33, Rowan Tommins a
écrit :
> On 19/06/2023 21:17, Nicolas Grekas wrote:
> > I think we must account for a bit of history/legacy on the topic.
> > I think session_set_save_handler(SessionHandlerInterface) is the best
> BC/FC
> > path we ca
Le mer. 14 juin 2023 à 23:51, Máté Kocsis a écrit :
> >
> > Given that you've agreed that neither signature is "primary" or "better",
> > doesn't that argument apply equally to both signatures? If it's OK to
> force
> > anyone using individual callbacks to change their code, why is it not
> >
> > > I'm going to nitpick on the newly suggested names and argument order
> for
> > > the
> > > DatePeriod factory methods — althoughI do agree that they need to get
> > > created:
> > >
> > > createFromInterval(DateTimeInterface $start, DateInterval $interval,
> > > DateTimeInterface $end, int
>
> > As you have possibly already experienced, overloaded signatures cause
> > various smaller and bigger issues, while the concept is not natively
> > supported by PHP. That's why I drafted an RFC which intends to phase
> > out the majority of overloaded function/method signatures and also
> >
Le ven. 9 juin 2023 à 02:11, Larry Garfield a
écrit :
> On Thu, Jun 8, 2023, at 5:39 PM, Stephen Reay wrote:
>
> > Is there a specific reason `clone with (foo: $bar);` can’t simply pass
> > the arguments given to with(), to the __clone() magic method?
> >
> > It leaves the developer free to use
> On Tue, May 30, 2023, at 10:04 PM, Alexandru Pătrănescu wrote:
> > > On Tue, May 30, 2023, 19:39 Larry Garfield
> > wrote:
> > >
> > >> On Mon, May 29, 2023, at 11:22 PM, Máté Kocsis wrote:
> > >> > To be honest, the current behavior seemed like the natural choice
> for
> > >> > me, and I
Ilija Tovilo and I would like to offer another RFC for your consideration.
> It's been a while in coming, and we've evolved the design quite a bit just
> in the last week so if you saw an earlier draft of it in the past few
> months, I would encourage you to read it over again to make sure we're
> > > What about using a real closure to define the scope we need for
> cloning?
> > > That closure would take the cloned instance as argument to allow
> > > manipulating it at will.
> >
> > I believe someone mentioned that one previously in the thread.
>
>
> Yes, Nicolas mentioned me.
> I wanted
Hi all,
https://wiki.php.net/rfc/allow_casting_closures_into_single-method_interface_implementations
>
> https://wiki.php.net/rfc/allow-closures-to-declare-interfaces-they-implement
> https://wiki.php.net/rfc/structural-typing-for-closures
Thanks Larry for the nice introduction to those ideas.
Hi again,
Quite some time after mentioning the "clone with" construct the first time
> (at the end of the
> https://wiki.php.net/rfc/write_once_properties#run-time_behaviour
> section),
> finally I managed to create a working implementation for this feature which
> would make it possible to
Hi Mate,
Quite some time after mentioning the "clone with" construct the first time
> (at the end of the
> https://wiki.php.net/rfc/write_once_properties#run-time_behaviour
> section),
> finally I managed to create a working implementation for this feature which
> would make it possible to
Hi all,
> > I've submitted https://github.com/php/php-src/pull/11126 to add support
> for final anonymous classes, though as noted by iluuu1994, it would
> probably make more sense to just make all anonymous classes final by
> default, what do you think?
> >
> > Extending an anonymous class is
Hi Rowan, hi all!
Le ven. 17 mars 2023 à 15:51, Larry Garfield a
écrit :
> On Thu, Mar 16, 2023, at 6:05 PM, Rowan Tommins wrote:
> > On 16/03/2023 22:14, Larry Garfield wrote:
> >> Wouldn't the functionality described boil down to essentially just
> materializing into a few extra lines in the
Hello George,
Dan and I would like to propose a new core autoloading mechanism that fixes
> some minor design issues with the current class autoloading mechanism and
> introduce a brand-new function autoloading mechanism:
> https://wiki.php.net/rfc/core-autoloading
>
> The existing SPL
> > To overcome the issues spotted in the thread, what about doing some sort
> > of CPP instead of autocapture?
> >
> > new class (...$arguments) use ($outer) extends Foo {
> > public function getIt() {
> > return $this->outer;
> > }
> > }
> >
> > This would be the equivalent of
Hi Rowan,
I have been pondering for a while how to improve the anonymous class
> syntax to allow "capturing" of values from the outer scope, and came up
> with the idea of a special variable marker for "lexically captured
> variable" - instead of $foo, you would write $!foo or $^foo (I quite
>
Hi Matthew,
> We've just opened the vote for the "Readonly amendments" RFC, which is
> > going to be open for 2 weeks (until 2023-02-07).
> >
> > Link: https://wiki.php.net/rfc/readonly_amendments
> > Discussion: https://externals.io/message/119007
> >
>
> I missed something when reviewing
> On 1/19/23 18:43, Ilija Tovilo wrote:
> > You're right, we'll try to improve the wording and provide a handful of
> > examples. Essentially, $callingScope should contain the class name of
> > the calling scope, so the place where the magic method was called. When
> > the calling scope is not a
Hi internals,
Ilija and I would like to start a discussion about the following RFC:
https://wiki.php.net/rfc/pass_scope_to_magic_accessors
When using magic methods to access actual properties, respecting their
declared visibility is often desired. Yet, accessing the calling scope to
emulate the
Hi George,
Hello Internals,
>
> I would like to start the discussion about the Add SameSite cookie
> attribute parameter RFC:
> https://wiki.php.net/rfc/same-site-parameter
>
> This proposes to add an optional same site parameter to the setrawcooki(),
> setcookie() and session_set_cookie_params()
Le mar. 10 janv. 2023 à 00:00, Larry Garfield a
écrit :
> On Mon, Jan 9, 2023, at 10:00 AM, Nicolas Grekas wrote:
> >> I am hereby opening the vote on the Asymmetric Visibility RFC:
> >>
> >> https://wiki.php.net/rfc/asymmetric-visibility
> >&g
> I am hereby opening the vote on the Asymmetric Visibility RFC:
>
> https://wiki.php.net/rfc/asymmetric-visibility
>
> Voting will be open for 2 weeks.
>
> While we would certainly prefer if everyone voted in favor, for those who
> vote against the authors kindly request that you indicate why,
Hi Ilija,
> I'd like to propose a simple RFC to introduce looking up class
> > constants by name. We have dedicated syntax for basically all other
> > language constructs. This RFC aims to get rid of this seemingly
> > arbitrary limitation.
> >
> >
Le ven. 2 déc. 2022 à 12:32, Ilija Tovilo a écrit :
> Hi Stephen
>
> > So here’s my last attempt:
> >
> > Please change this behaviour in your rfc.
> >
> > You are explicitly making it mutually exclusive with readonly now, so
> that’s not a bc break - if/when it becomes compatible with readonly
The code that Marco (Pivetta) shared was supposed to illustrate how
readonly classes can be useful to enforce some invariants on child classes.
Yet, here is another implementation that does use a readonly child class,
but still provides the behavior that was supposedly prevented by the
keyword:
> > The other failing tests involve "unserialize_callback_func" to gracefully
> > detect class-not-found, and they are all plain broken by the RFC.
> >
> > I created this patch/PR to show the changes that would be required on
> > Symfony to work around the BC break:
> >
due to exceeding 3 bytes:
>
> > ezmlm-reject: fatal: Sorry, I don't accept messages larger than 3
> bytes (#5.2.3)
>
> You can find the attachments at:
> https://gist.github.com/TimWolla/376dd162f7684daef38f76a07254871c
>
> Original message below:
>
> --
nts. I created
> this
> > gist to list all the failures:
> > https://gist.github.com/nicolas-grekas/3da652a51669baa40c99bd20e4a1b4dd
> >
> > Maybe I wasn't convincing enough during the discussion period, but that
> > doesn't change the fact that the proposed behavior in
why I didn't think about it before but I just ran the test suite
of Symfony after applying the patch proposed in the RFC to change the way
exceptions are handled by unserialize.
This change breaks the test suite of 5 separate components. I created this
gist to list all the failures:
https://gist.g
Hi Tim,
I'm not quoting the full text of the discussion because the php ML server
refused the message - too long it said.
> this gist:
> > https://gist.github.com/nicolas-grekas/5dd3169f94ed3b4576152605330824fe
> >
> >
>
> [...] (see previous messages on the t
>
> > When I was working on the readonly class RFC, I realized that the
>> readonly
>> > keyword very naturally fits services besides value objects. So my
>> > expectation has been that until we can fix the issue with cloning,
>> people
>> > would mainly apply readonly to services. Not that it is
Hi all,
> When I was working on the readonly class RFC, I realized that the readonly
> keyword very naturally fits services besides value objects. So my
> expectation has been that until we can fix the issue with cloning, people
> would mainly apply readonly to services. Not that it is very
Hi Tim,
I'm a bit busy with conferences these days...
On 9/12/22 21:46, Nicolas Grekas wrote:>> unserialize() is a generic
> function that will also call arbitrary
> >> callbacks. You already have no guarantees whatsoever about the kind of
> >> exception that is
> >> Personally I'm undecided at the moment whether or not it should be
> >> allowed. I'm sympathetic to the "it's easier to disallow and allow
> later
> >> than vice versa" argument, but still not sure where I stand. The above
> at
> >> least gives a concrete example of where the problem would
> On 9/8/22 19:06, Nicolas Grekas wrote:
> > From what I understand, there are two things in the RFC:
> >
> > 1. a proposal to wrap any throwables thrown during unserialization
> > inside an UnserializationFailedException
>
> Correct.
>
> > 2
Hello Larry,
> Regarding your main question: I understand your problem with readonly
> > classes, and I'd be happy if we found a solution which fits your
> use-cases
> > and keeps consistency for the engine at the same time. To give you more
> > context about the inheritance related restriction
Hi Tim,
Thanks for the RFC.
I've now written up an RFC as a follow-up for the "What type of
> Exception to use for unserialize() failure?" thread [1]:
>
>
>
> RFC: Improve unserialize() error handling
> https://wiki.php.net/rfc/improve_unserialize_error_handling
>
> Proof of concept
Hi Mate
For 2.: static properties are useful e.g. to cache some shared state (info
>> extracted from reflection in my case) and I really don't see why readonly
>> classes should forbid static properties. Readonly is only useful for
>> instances, because it gives them immutability, but what's the
>Hi Marco,
> >
> >IMO good as-is: can be relaxed later (8.3 or later), if anybody believes
> >> it's a show-stopper.
> >>
> >Readonly classes don't really need to be lazy.
> >>
> >
> >"Break things and move slow" doesn't feel right to me for the language.
>
> It's a new keyword that you have to
Hi Marco,
IMO good as-is: can be relaxed later (8.3 or later), if anybody believes
> it's a show-stopper.
>
Readonly classes don't really need to be lazy.
>
"Break things and move slow" doesn't feel right to me for the language.
Maybe you don't see the need for lazy readonly classes, but that's
Hello everybody, hi Mate
I played with readonly classes recently, to add support for them to
lazy-loading proxy generation and I struggled upon what I see as serious
issues.
As noted in the RFC, and because the readonly flag must be set on child
classes, those cannot:
1. Declare a new
> Ilija Tovilo and I are happy to present the first new RFC for PHP 8.3:
> Asymmetric Visibility.
>
> https://wiki.php.net/rfc/asymmetric-visibility
>
> Details are in the RFC, but it's largely a copy of Swift's support for the
> same.
>
Thank you Larry and Ilija for this RFC.
After reading it,
> Hi internals,
>
> I opened voting for the new Curl URL API as part of PHP8.2.
>
> All recent discussions show that we are not even close to getting a
> consensus on how the new CurlUrl OO API should be done. After changing my
> mind 300 times in the last day, I decided to only propose the
Hi there,
Greetings, Internalians.
>
> The vote for auto-capture closures is now open. It will run until 15 July.
>
> https://wiki.php.net/rfc/auto-capture-closure
>
Thanks for the RFC, I voted yes as I think the optimized auto-capturing
logic is sound.
Having "function()" still be a
> > Hi everyone
> >
> > I'd like to start a discussion on a simple RFC to allow fetching
> > properties in constant expressions.
> > https://wiki.php.net/rfc/fetch_property_in_const_expressions
> >
> > The RFC proposes adding support for fetching properties in constant
> > expressions using the ->
Hi Guilliam,
> > There are also cases where using "->value" is just not possible. I
> mention
> > attributes in the RFC,
>
> which also mentions
> https://wiki.php.net/rfc/fetch_property_in_const_expressions (but with
> "For people that use non-strict mode, this extra “->value” is
> boilerplate
> domain SymfonyPermission: string;
> domain AcmePermission: string { 'admin' | 'user' | 'bot' };
> [...]
> Domains can also be considered sets, which you could compare directly,
> and maybe even calculate intersections, unions, etc:
>
> The actual values would be ordinary strings, and type
> >
> > I'd like to start a discussion on an RFC to allow defining constants in
> traits.
> > https://wiki.php.net/rfc/constants_in_traits
> >
> > I'm looking forward to your feedback, including corrections on English
> wordings.
> >
> > Thanks!
> >
> > --
> > Shinji Igarashi
>
> I am initially
Hi Benjamin and Derick,
I'm replying to both of you because I see some things in common in your
comments.
>https://wiki.php.net/rfc/auto-implement_stringable_for_string_backed_enums
I would prefer if this was an explicit opt-in to have a __toString on a
> backed enum. Maybe a special trait for
Hi everyone!
I'd like to open a discussion on this RFC, to auto-implement Stringable for
string-backed enums:
https://wiki.php.net/rfc/auto-implement_stringable_for_string_backed_enums
I'm looking forward to your feedback,
Cheers,
Nicolas
> An RFC has been created to fix an issue in Random Extension 5.x.
>
> https://wiki.php.net/rfc/random_extension_improvement
>
> Voting on this RFC will begin in two weeks (2022-07-02), in time for the
> PHP 8.2 Feature Freeze. (Vote finished in 2022-07-16, Feature Freeze is
> 2022-07-19)
>
> In
Le ven. 22 oct. 2021 à 15:41, Dylan K. Taylor a écrit :
>
> On Fri, 22 Oct 2021 14:19:23 +0100 Claude Pache <
> claude.pa...@gmail.com> wrote
>
> >
> > Le 21 oct. 2021 à 01:12, Dylan K. Taylor a écrit :
> >
> > Hi all,
> >
> > Given the addition of Closure::fromCallable() and
Le jeu. 31 mars 2022 à 17:50, Larry Garfield a
écrit :
> On Thu, Mar 31, 2022, at 10:45 AM, Ilija Tovilo wrote:
> > Hi everyone
> >
> > We've had two bug reports for var_export not working for enums. The
> > reason for that is that var_export does not add a leading backslash to
> > names of
> > to me this closes extensibility in a hard way.
>
> This is not necessarily true, we have `final` in PHP which does exactly
> that, but `sealed` can still allow for extensibility, just from a different
> point, e.g:
>
`final` has the same issue to me: it's a feature of the language that would
Le jeu. 17 mars 2022 à 04:54, Saif Eddin Gmati a
écrit :
> Hello Internals,
>
> As per my last email in the previous thread, i have started the vote for
> sealed classes feature.
>
> The vote will run for 2 weeks until March 31st 2022.
>
> Discussion: https://externals.io/message/117173
>
>
Le mer. 23 févr. 2022 à 17:59, Christoph M. Becker a
écrit :
> On 23.02.2022 at 16:29, Nicolas Grekas wrote:
>
> > Le mar. 22 févr. 2022 à 14:56, Marco Pivetta a
> écrit :
> >
> >> On Tue, Feb 22, 2022 at 2:53 PM Nicolas Grekas <
> &g
Le mar. 22 févr. 2022 à 14:56, Marco Pivetta a écrit :
> On Tue, Feb 22, 2022 at 2:53 PM Nicolas Grekas <
> nicolas.grekas+...@gmail.com> wrote:
>
>>
>> But this makes me think: we should trigger a deprecation just before all
>> corresponding warnings!
>>
&
Le mar. 22 févr. 2022 à 12:07, Mark Randall a écrit :
> On 22/02/2022 09:15, Nicolas Grekas wrote:
> > I very much call for an implementation to be provided before starting any
> > vote on the topic btw.
> The RFC states on its first line that accessing an undefined variable
&g
Le ven. 18 févr. 2022 à 12:24, Rowan Tommins a
écrit :
> On 17/02/2022 23:28, Mark Randall wrote:
> > I present:
> >
> > https://wiki.php.net/rfc/undefined_variable_error_promotion
>
>
> It would be good to have a "Scope" or "Unaffected Functionality" section
> here, because there are a number
Le jeu. 25 nov. 2021 à 12:23, Tim Starling a
écrit :
> On 25/11/21 8:58 pm, Nicolas Grekas wrote:
>
>
> The RFC says:
> > because they also use isdigit() and isspace(),
>
> Does that mean "too much work needed"? I would totally understand that of
> course b
Le jeu. 25 nov. 2021 à 11:34, Christoph M. Becker a
écrit :
> On 25.11.2021 at 10:58, Nicolas Grekas wrote:
>
> > Le jeu. 25 nov. 2021 à 10:47, Tim Starling a
> > écrit :
> >
> >> and because they are intended for natural language processing
> >
> >
Le jeu. 25 nov. 2021 à 10:47, Tim Starling a
écrit :
> On 25/11/21 7:55 pm, Nicolas Grekas wrote:
>
>
> I voted yes because I want to see this happen but I raised a point in
> https://externals.io/message/116141#116259 and didn't get an answer:
>
> Despite their name,
Le jeu. 25 nov. 2021 à 06:05, Tim Starling a
écrit :
> Voting is now open for my RFC on locale-independent case conversion.
>
> https://wiki.php.net/rfc/strtolower-ascii
>
> Voting will close in two weeks, on 2021-12-09.
>
Hi Tim,
I voted yes because I want to see this happen but I raised a
Hi Nikita, hi everybody,
Le mer. 25 août 2021 à 12:03, Nikita Popov a écrit :
> Hi internals,
>
> I'd like to propose the deprecation of "dynamic properties", that is
> properties that have not been declared in the class (stdClass and
> __get/__set excluded, of course):
>
>
Le lun. 11 oct. 2021 à 03:33, Tim Starling a
écrit :
> On 4/10/21 9:08 pm, Nikita Popov wrote:
> >
> > Hi Tim,
> >
> > Thanks for creating this proposal, it looks great!
> >
> > I think this is a very beneficial change, and the amount of
> > incorrect locale-dependent calls we had just in
Le dim. 26 sept. 2021 à 14:42, Jordi Boggiano a écrit :
>
> > I'm surprised that is_resource() returns false for resource objects,
> > does anyone knows why it wouldn't return true in such case ?
> >
> > This is a very weird behavior, I'd expect it to return true, moreover
> > this is the most
Hi Nikita
Hi internals,
>
> I'd like to pick up a loose thread from the future scope of the
> https://wiki.php.net/rfc/static_return_type RFC, the $this return type for
> fluent APIs:
>
> https://wiki.php.net/rfc/this_return_type
>
> I have some reservations about this (which basically come down
> In the thread for deprecation of dynamic properties, Rowan suggested that
> we alias "stdClass" to "DynamicObject" in
> https://externals.io/message/115800#115802. I wanted to split this
> discussion off into a separate thread, as this can be decided
> independently.
>
> The rationale for this
Hi everyone,
I'm happy to announce that the vote for nullable intersection types is now
> open:
> https://wiki.php.net/rfc/nullable_intersection_types
>
> It'll close in two weeks, on the 27th.
>
The vote is now closed with a total of 38 votes: 26 against and 12 in favor.
The RFC is declined.
Le mer. 25 août 2021 à 19:32, Marco Pivetta a écrit :
> Hey Nicolas,
>
>
> On Wed, Aug 25, 2021 at 7:30 PM Nicolas Grekas <
> nicolas.grekas+...@gmail.com> wrote:
>
>> I would welcome a new RFC to clarify what is allowed during the feature
>> freeze.
>
Le mar. 24 août 2021 à 08:09, Pierre Joye a écrit :
> Hi Marco,
>
> On Tue, Aug 24, 2021 at 3:49 AM Deleu wrote:
> >
> > Hello everyone!
> >
> > We recently had the Nullable Intersection Types RFC process in an
> > unconventional way starting a new RFC post feature freeze. If memory
> serves
>
Le mar. 24 août 2021 à 21:09, Derick Rethans a écrit :
> On 24 August 2021 19:53:57 BST, Deleu wrote:
> >On Tue, Aug 24, 2021, 19:28 Derick Rethans wrote:
> >
> >> On Mon, 23 Aug 2021, Deleu wrote:
> >>
> >> > We recently had the Nullable Intersection Types RFC process in an
> >> >
Le lun. 23 août 2021 à 16:22, Larry Garfield a
écrit :
> On Sun, Aug 22, 2021, at 5:42 PM, Patrick ALLAERT wrote:
>
> > Either extra time, or having a way to influence the schedule of the
> > releases.
> > For now, we work with a fixed schedule and don't know (at least: me) how
> > strict we
>
> On Mon, 16 Aug 2021 at 10:04, Nikita Popov wrote:
>
>> On Mon, Aug 16, 2021 at 9:45 AM Joe Watkins wrote:
>>
>>> Morning all,
>>>
>>> The initial RFC was clear that nullability was not supported, however
>>> that
>>> doesn't seem to be have widely understood.
>>>
>>> When I said we should
Hi everyone,
I'm happy to announce that the vote for nullable intersection types is now
open:
https://wiki.php.net/rfc/nullable_intersection_types
It'll close in two weeks, on the 27th.
Cheers,
Nicolas
> On 11/08/2021 13:09, Nicolas Grekas wrote:
> >
> > On 10/08/2021 13:39, Nicolas Grekas wrote:
> > > I will wait if I don't have the choice, but as many others
> > reported, the
> > > experience with 7.0 missing nullability was a pain.
&
>
> 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 everything down about the reasons why here:
>
> On 10/08/2021 13:39, Nicolas Grekas wrote:
> > I will wait if I don't have the choice, but as many others reported, the
> > experience with 7.0 missing nullability was a pain.
>
> Apologies if you already did and I've forgotten, but could you please
> expand on what
> 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 everything down about the reasons why here:
>
1 - 100 of 314 matches
Mail list logo
