a different mechanism so you
can use standard conditional branching.
As such, there are a lot of situations where I may not want to use
exceptions. Two common ones:
* Input validation. In most cases, _invalid input is expected_, and a
condition you will handle in your code. Exceptions are a really poor
mechanism for this.
* "Not found" conditions, such as not finding a matching row in a database
or a cache. Again, this is expected, and something you should handle via
conditionals.
Currently, there's no _generic_ way to handle these sorts of error
conditions from functions. You can create "result" types specific to each
operation, but this is a lot of boilerplate. You can resort to exceptions,
but these are a poor fit due to performance and logic flow.
I'm currently not yet convinced on the proposal Larry is making, but I
definitely understand what's driving it, and would love a language-level
solution.
--
Matthew Weier O'Phinney
mweierophin...@gmail.com
https://mwop.net/
he/him
On Mon, Aug 26, 2024 at 3:45 PM John Coggeshall wrote:
>
>
> On Aug 26 2024, at 2:11 pm, Matthew Weier O'Phinney <
> mweierophin...@gmail.com> wrote:
>
>
> I can see a few others:
>
> - string concatenation. I might want to prepend or append a stri
On Mon, Aug 26, 2024, 12:02 PM Larry Garfield
wrote:
> On Mon, Aug 26, 2024, at 6:36 AM, Jakob Givoni wrote:
> > On Mon, Aug 26, 2024 at 12:49 PM Rowan Tommins [IMSoP]
> > wrote:
> >> On Mon, 26 Aug 2024, at 10:14, Bilge wrote:
> >> > You're absolutely right, I would be interested to see any via
On Sun, Aug 25, 2024, 9:06 AM John Coggeshall wrote:
>
>
> On Aug 24 2024, at 12:49 pm, Bilge wrote:
>
> Hi gang,
>
> New RFC just dropped: https://wiki.php.net/rfc/default_expression. I
> think some of you might enjoy this one. Hit me with any feedback.
>
>
> Seems like you are missing an optio
On Sat, Aug 24, 2024, 11:50 AM Bilge wrote:
> Hi gang,
>
> New RFC just dropped: https://wiki.php.net/rfc/default_expression. I
> think some of you might enjoy this one. Hit me with any feedback.
>
This is a feature I've wanted for a very long time! The RFC is very
straight forward, and the appe
On Tue, Aug 20, 2024, 4:56 PM Rob Landers wrote:
>
>
> On Tue, Aug 20, 2024, at 18:07, Rob Landers wrote:
>
> On Tue, Aug 20, 2024, at 08:50, Rowan Tommins [IMSoP] wrote:
>
>
>
> On 20 August 2024 00:21:22 BST, Rob Landers wrote:
> >
> >I assume you are worried about something like this passing
> On 13 Aug 2024, at 13:43, Gina P. Banyard wrote:
>
> On Tuesday, 13 August 2024 at 14:05, Matthew Sewell wrote:
>
>>> On 13 Aug 2024, at 12:36, Gina P. Banyard intern...@gpb.moe wrote:
>>>
>>> On Tuesday, 30 July 2024 at 11:49, Gina P. Banyard i
> On 13 Aug 2024, at 12:36, Gina P. Banyard wrote:
>
> On Tuesday, 30 July 2024 at 11:49, Gina 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
On Tue, Jul 23, 2024 at 9:06 AM Larry Garfield
wrote:
> On Tue, Jul 23, 2024, at 1:42 PM, Matthew Weier O'Phinney wrote:
> > On Fri, Jul 19, 2024 at 12:41 PM Gina P. Banyard
> wrote:
> >> Hello internals,
> >>
> >> I have opened the vote for the meg
no mention of this character as a wildcard anywhere in that
RFC.
Can somebody clarify?
--
Matthew Weier O'Phinney
mweierophin...@gmail.com
https://mwop.net/
he/him
On Sat, Jul 20, 2024, 9:31 AM Tim Düsterhus wrote:
> Hi
>
> On 7/19/24 00:51, Christoph M. Becker wrote:
> > And frankly, how much code would be affected? I mean, does anybody
> > actually put a comment between `yield` and `from`? Is there a case
> > where this may make sense? "Because we can"
what problems_ the current approach of
using namespaced code doesn't address. I can definitely see a need for
marking things as package private (i.e., not part of the publicly
consumable API), but that also feels like something we could address in
other ways. I know Larry has asked this same question before, and it's
really what I want to see answered, because packages might be the solution,
but there may be other approaches we could take that also accomplish those
goals.
--
Matthew Weier O'Phinney
mweierophin...@gmail.com
https://mwop.net/
he/him
On Mon, Jun 24, 2024, 7:35 PM Stephen Reay wrote:
>
> Sent from my iPhone
>
> On 24 Jun 2024, at 23:43, Matthew Weier O'Phinney <
> mweierophin...@gmail.com> wrote:
>
>
>
>
> On Mon, Jun 24, 2024 at 10:08 AM Nicolas Grekas <
> nicolas.grekas+...@g
quot; format to mimic the notation that
Composer uses on the CLI when specifying a package with a constraint:
"symfony/yaml:7.2.0". This can be parsed easily, and won't suffer from
having arbitrary spacing and version naming prefixes.
(Still would prefer a "scheduledRemoval" field, as knowing when it was
deprecated is far less interesting than knowing when it will be removed.
Yes, I can assume the next major version, but what if it's major version +
1? What if a project allows removals during minor releases? Knowing what
version it will be removed in makes it far easier to understand what will
happen when I upgrade next.)
--
Matthew Weier O'Phinney
mweierophin...@gmail.com
https://mwop.net/
he/him
On Thu, Jun 20, 2024, 1:27 PM Niels Dossche wrote:
> On 20/06/2024 16:28, Matthew Weier O'Phinney wrote:
> >
> >
> > On Mon, Jun 10, 2024 at 1:15 PM Niels Dossche <mailto:dossche.ni...@gmail.com>> wrote:
> >
> > Hi internals
> >
> &g
Niels
>
Question: why is `Dom\Document::$head` marked as readonly?
--
Matthew Weier O'Phinney
mweierophin...@gmail.com
https://mwop.net/
he/him
On Mon, Jun 3, 2024 at 9:46 AM Ilija Tovilo wrote:
> Hi Matthew
>
> On Mon, Jun 3, 2024 at 3:15 PM Matthew Weier O'Phinney
> wrote:
> >
> > On Wed, May 22, 2024 at 2:24 AM Benjamin Außenhofer
> wrote:
> >>
> >> The vote for the RFC #[\
eprecated. What would be far more
useful to a consumer is an argument indicating when something will be
removed (e.g. $toRemoveInVersion, $versionForRemoval, etc.). This helps me
as a user plan for the future.
--
Matthew Weier O'Phinney
mweierophin...@gmail.com
https://mwop.net/
he/him
e);
// read the stream
and
$writer = XMLWriter::toStream($streamHandle);
// write to the stream
My understanding is that the implementations will allow for subclassing.
Having these as instance methods means that subclasses would need to
potentially add handling to ensure the instance is not in an invalid state
(e.g., by switching streams mid-flight), which would add far more edge
cases to handle.
--
Matthew Weier O'Phinney
mweierophin...@gmail.com
https://mwop.net/
he/him
>
> What's the advantage of a language construct over the following?
>
> ```php
> /**
> * @template T of object
> * @psalm-assert T $value
> * @param class-string $type
> */
> function as(mixed $value, string $type): mixed
> {
> if (! $value instanceof $type) { throw
> SomeKindOfException::
ame less applicable, and inconsistent with what other
> languages call it.
>
> However, changing it back at this point would be a non-small amount of
> grunt work. There would be no functional changes from doing so, but it’s
> lots of renaming things both in the PR and the RFC. We are willing to do so
> if the consensus is that it would be beneficial, but want to ask before
> putting in the effort.
>
I personally would go with just "accessors".
--
Matthew Weier O'Phinney
mweierophin...@gmail.com
https://mwop.net/
he/him
Hi,
I'm using Gmail too but with a custom domain. I did get those three
messages but significantly delayed from when they were on externals.
Best wishes,
Matt
On Sat, Feb 17, 2024 at 4:15 PM tag Knife wrote:
>
> On Fri, 16 Feb 2024 at 23:50, Jorg Sowa wrote:
>
>> Hello Derick,
>> there is so
code is seemingly the minority.)
>
But I DO agree with the above. So this might be a time for us to start
discussing if/when we want a PHP 9 to occur.
>
>
--
Matthew Weier O'Phinney
mweierophin...@gmail.com
https://mwop.net/
he/him
On Tue, Nov 28, 2023, 5:28 PM Derick Rethans wrote:
> On 28 November 2023 17:28:18 GMT, Sebastian Bergmann
> wrote:
>
> >While we could probably replace __DATE__ and __TIME__ with
> SOURCE_DATE_EPOCH [3] [4], I cannot help but wonder whether having the date
> and time when the executable was bui
On Fri, Sep 8, 2023, 9:15 AM Lanre Waju wrote:
> Allowing Methods in Structs:
> Initially, I suggested that readonly structs have no methods besides the
> constructor. However, upon further consideration, I believe it may be
> beneficial to allow methods in structs. Even PHP enums allow methods,
> On 15 May 2023, at 19:51, Rowan Tommins wrote:
>
> On 15 May 2023 19:38:56 BST, Larry Garfield wrote:
>
>> I agree entirely. Setting reasonable expectations for users to plan around,
>> such as a known 5-years-per-major cycle, helps end users far more than
>> "whelp, we did something big
>
> Regarding $field vs. $this->propName, there's a few reasons we went that
> route.
Overall I think this is a really good proposal, but you might want to
consider a second vote for that particular syntax.
`$field` vs `$this->propName` feels a little magical. It's a simpler magic
than actual ma
On Sun, Apr 23, 2023, 3:33 PM Casper Langemeijer
wrote:
> Nothing seems to happen on this front, and our Windows users like to move
> to PHP 8.2 too.
>
> The windows.php.net site states: "This is because the Windows PECL build
> machine died, and the team is still working on the long term plan of
> On 13 Apr 2023, at 09:29, Andreas Heigl wrote:
>
> Hey all
>
> On 12.04.23 22:44, Larry Garfield wrote:
>> On Wed, Apr 12, 2023, at 6:42 PM, Rowan Tommins wrote:
>>> Which brings me back to my earlier point: I wonder how much of the
>>> reaction is really about e-mail itself, and how much i
idea (I have a separate problem in that
our projects are rarely on GitHub or GitLab) but does anybody who would
actually benefit from it have any thoughts on whether it would be good for them
or not?
> On 11 Apr 2023, at 10:09, Matthew Sewell wrote:
>
> What's meaningful in this
What's meaningful in this sense?
I have a budget for supporting open source projects (back to my money v time
point) and a percentage of that is for the PHP Foundation. I'd happily pay LTS
fees we pay elsewhere (even sometimes as a safety net) to the Foundation but
believe that the money we giv
Hi,
This is a really interesting thread and am glad that Stephan raised it as I've
been thinking along similar lines for a while now and am glad I'm not the only
one.
Considering the range of people adding comments (especially someone like Mark)
then I would hope everyone agrees that this dese
t; headers instead of
the specific headers for the symbols they use? Probably not. Will forcing
the issue without giving them a chance to review and understand the
changes, and have a roadmap for when and how those changes occur be a net
positive? No; it will cause a lot of busy work for a lot of p
On Fri, Aug 5, 2022, 12:09 PM Larry Garfield wrote:
> 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.
>
I have
On Thu, Nov 25, 2021, 12:17 PM Máté Kocsis wrote:
> Sorry Folks, but I have to provide some update about the results:
>
> Unfortunately, due to a silly bug in my calculator code, the % differences
> in the benchmark results were slightly off from their real values, so I
> have just retroactively
On Thu, Nov 18, 2021, 7:32 AM Nikita Popov wrote:
> On Thu, Nov 18, 2021 at 2:07 PM Patrick ALLAERT
> wrote:
>
> > Le mer. 17 nov. 2021 à 13:30, Christoph M. Becker a
> > écrit :
> > > Right. An alternative might be to let users report security issues to
> > > the security mailing list, where,
On Mon, 15 Nov 2021 at 17:32, Chase Peeler wrote:
>
>
> On Mon, Nov 15, 2021 at 4:40 PM Matthew Brown
> wrote:
>
>
>> I encourage people to vote "yes" on this, if you want PHP to be better at
>> preventing people from shooting themselves in the foo
On Fri, 12 Nov 2021 at 08:08, Nikita Popov wrote:
> Hi internals,
>
> I've opened the vote on
> https://wiki.php.net/rfc/deprecate_dynamic_properties. Voting will close
> 2021-11-26.
>
> Regards,
> Nikita
>
There are two things developers think about when releasing code:
1. does it work for me
On Fri, Nov 12, 2021, 3:41 PM Larry Garfield wrote:
> On Fri, Nov 12, 2021, at 12:59 PM, Matthew Weier O'Phinney wrote:
> > I recognize it's a bit late to be commenting, now that voting has
> > started... but this feels like a solution for which we already have
> >
annot
understand what drives it.
On Fri, Nov 12, 2021 at 7:08 AM Nikita Popov wrote:
> Hi internals,
>
> I've opened the vote on
> https://wiki.php.net/rfc/deprecate_dynamic_properties. Voting will close
> 2021-11-26.
>
> Regards,
> Nikita
>
--
Matthew Weier O'Phinney
mweierophin...@gmail.com
https://mwop.net/
he/him
On Wed, Sep 22, 2021 at 9:39 AM Calvin Buckley wrote:
> On Sep 22, 2021, at 11:24 AM, Matthew Weier O'Phinney <
> mweierophin...@gmail.com> wrote:
> > As somebody who's been contributing to and maintaining OSS libraries
> > forever (since 2002), the pace of cha
On Wed, Sep 22, 2021 at 9:01 AM G. P. B. wrote:
> On Wed, 22 Sept 2021 at 14:30, Matthew Weier O'Phinney <
> mweierophin...@gmail.com> wrote:
>
>> Yesterday, I opened an issue regarding a change in the pgsql extension (
>> https://bugs.php.net/bug.php?id=8146
code. I strongly feel that
anything in the backwards incompatible section of the UPGRADING guide
should be deferred to 9.0, when people actually expect things to change.
--
Matthew Weier O'Phinney
mweierophin...@gmail.com
https://mwop.net/
he/him
On Sat, 18 Sept 2021 at 12:04, Larry Garfield
wrote:
>
> I am frequently on-record hating on PHP arrays, and stating that I want
> something better. The problems with PHP arrays include:
>
> 1. They're badly performing (because they cannot be optimized)
> 2. They're not type safe
> 3. They're mu
I can also give some in-the-trenches perspective of vec's utility, having
spent the last month and a half writing Hack. vec is a really useful data
structure to be able to use explicitly in code. It makes code that uses it
easier to understand.
The main benefit over Vector is that it could be used
On Thu, 16 Sept 2021 at 23:33, tyson andre
wrote:
> Yeah, as mentioned in
> https://wiki.php.net/rfc/vector#adding_a_native_type_instead_is_vec , it
> would require a massive amount of work.
>
> - A standard library for dealing with `vec`, filtering it, etc
> - Userland libraries and PECLs would
> On Sep 6, 2021, at 11:29 AM, Nikita Popov wrote:
>
I think this would be a massive benefit to first-time PHP users one or two
years from now.
I remember being confused by this terminology — I am sure bugs have been caused
by people who assumed stdClass was a base class for all objects.
B
On Thu, 26 Aug 2021 at 21:20, Sara Golemon wrote:
> We're
> going to need to run some static analyzers on some frameworks and
> libraries. Who's got it in them to do the research?
>
> -Sara
>
I'm not volunteering, but I forked Nikita's package analysis to add Psalm
scanning a while ago: https:/
Hey!
Using the "never" type to require that downstream libs specify a type does
not make intuitive sense to me, because the same is not true the other way
(covariantly) for return types.
The existence of a "never" type on an overriding method does not require
that upstream libs specify a return t
On Sun, 18 Jul 2021 at 14:47, Tobias Nyholm wrote:
> There has not been many (maybe just one or two) RFCs where I wished the
> vote turned out the other way.
>
This was the reason that I did *not* think that I needed a vote, as a
prolific PHP coder — while individual voters might be voting the "
I've just added support for a `literal-string` type to Psalm:
https://psalm.dev/r/9440908f39
This will remain whether or not the RFC passes, but if it passes the
is_literal check will be used to inform Psalm in a similar fashion to how
array_is_list (coming in 8.1) will inform Psalm's list array t
On Mon, 14 Jun 2021 at 08:30, Dan Ackroyd wrote:
> Hi Craig, Joe,
>
> While I think the idea behind this RFC is great, the current
> implementation is terrible, as it will cause some fatal errors in
> production.
>
>
I'm not sure it's productive to call the implementation terrible. With
Someniatk
On Sat, 12 Jun 2021 at 13:00, Craig Francis
wrote:
> Hi Internals,
>
> I'd like to start the discussion on the is_literal() RFC:
>
> https://wiki.php.net/rfc/is_literal
>
> is_literal() brings a proven way to identify Injection Vulnerabilities to
> PHP, already used by Google in their Java and Go
This is a great idea!
Might be worth mentioning that Psalm already supports a `@readonly`
docblock annotation (first suggested by Nuno Maduro), and it matches the
proposed behaviour (though Psalm doesn't currently prevent inheritance
issues):
Example: https://psalm.dev/r/7ed5872738
On Fri, 4 Jun
On Thu, 20 May 2021 at 10:17, Ondřej Mirtes wrote:
> Hi, I’m confused by the syntax, when I read it, I think to myself “I know
> this, this is just a method call… oh wait, it’s actually a callable”. It
> really makes my head hurt.
>
I agree with the first point — slightly confusing initially, bu
On Tue, 4 May 2021 at 06:34, Nikita Popov wrote:
> Hi internals,
>
> I'd like to present an RFC for property accessors:
> https://wiki.php.net/rfc/property_accessors
>
> Property accessors are like __get() and __set(), but for a single property.
> They also support read-only properties and proper
On Sun, 25 Apr 2021 at 16:12, David Rodrigues
wrote:
> I know that this discussion comes back from time to time, but now that PHP
> is quite strong in relation to argument typing, I think it is worthwhile to
> have a quick discussion about it. Maybe to PHP 9.
>
> One of the things I remember that
> On Apr 24, 2021, at 10:43 AM, Levi Morrison via internals
> wrote:
>
> On Sat, Apr 24, 2021 at 8:04 AM Benjamin Eberlei wrote:
>>
>>> On Sat, Apr 24, 2021 at 2:56 PM Pierre wrote:
>>>
>>> Le 24/04/2021 à 12:55, Saif Eddin Gmati a écrit :
Hello Internals,
I'm sending this
contributed comments and suggestions!
Matt and Ondřej
> On Mar 30, 2021, at 11: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
>
> Best wishes,
>
> Matt and Ondrej
On Sat, 3 Apr 2021 at 22:29, David Rodrigues wrote:
> It is very likely that the proposal will be accepted (it is already 33/10),
>
I'm definitely not counting my chickens.
> Is there any chance of discussing terms, even if the "never" indication is
> winning at the moment? Or did I miss this
On Sat, 3 Apr 2021 at 12:30, Benjamin Eberlei wrote:
>
> But adding a new keyword "noreturn" would not be necessary, it could just
> be an Attribute as i said in my first e-mail explaining my no-vote:
>
> #[NoReturn] // sets a function flag modifying the void behavior
> public function foo(): not
On Tue, 30 Mar 2021 at 13:51, Ilija Tovilo wrote:
> Hi Matthew
>
> > I like the proposal. I also support the covariance.
> >
> > One question though.
> > The RFC mentions possible future use of "nothing" as a bottom type for
> > parameters in g
On Thu, 1 Apr 2021 at 04:56, Benjamin Eberlei wrote:
> This RFC is using the declaration of the return type, to specify that it
> never returns. As such noreturn or never is a keyword a long the lines of
> public or final, but it is not a return type.
>
> I don't think the argument for potential
On Wed, 31 Mar 2021 at 09:30, Theodore Brown 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 <
> matthewmatt...@gmail
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 noreturn is now open:
> >
> > https://wiki.php.net/rfc/noreturn_type
> >
> > Voting
Hey everyone!
The vote for adding noreturn is now open:
https://wiki.php.net/rfc/noreturn_type
Voting will run through April 13th
Best wishes,
Matt and Ondrej
> On Mar 29, 2021, at 1:25 PM, Ilija Tovilo wrote:
>
> Hi Matthew
>
>> Ondřej Mirtes and I present an RFC for the noreturn type:
>> https://wiki.php.net/rfc/noreturn_type
>>
>> The feature already exists in Hack (the primary inspiration) and is
>>
If there are no more questions, we plan to open up voting for this on Tuesday
March 30. There will be two votes — a 2/3 majority required for the feature,
and a simple majority required for the name — “noreturn” vs “never”.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, v
On Thu, 25 Mar 2021 at 12:24, Nuno Maduro wrote:
> Hi,
>
> Concerning the comments about what's exactly "auto-captured" by the scope
> of a multi-line short closure, we will be just reusing the "auto-capture"
> feature that already exists in one-line short closures. Therefore, this RFC
> doesn't
On Thu, 25 Mar 2021 at 10:23, Christian Schneider
wrote:
> Am 25.03.2021 um 14:29 schrieb Mark Randall :
> > On 25/03/2021 09:28, Rowan Tommins wrote:
> >> That's not quite what I meant. I meant that you can't say "capture by
> default, but this variable is definitely local".
> >
> > I think if t
On Tue, 23 Mar 2021 at 05:32, G. P. B. wrote:
> I'm calling this proposal pure intersection types as there would be no
> possibility of mixing intersection and union types, I'm leaving this as a
> future scope.
>
Does this miss an opportunity, though? It's useful to be able to write
A&B|null.
On Sat, 20 Mar 2021 at 11:35, Larry Garfield wrote:
> My main concern is around the covariance of inheritance. The example
> given:
>
> abstract class Person
> {
> abstract public function hasAgreedToTerms(): bool;
> }
>
> class Kid extends Person
> {
> public function hasAgreedToTerms()
On Fri, 19 Mar 2021 at 10:53, Nikita Popov wrote:
> On Fri, Mar 19, 2021 at 3:45 PM Marco Pivetta wrote:
>
>> Hey Nikita,
>>
>> On Fri, Mar 19, 2021, 14:35 Nikita Popov wrote:
>>
>>>
>>> Is it allowed to declare a noreturn function that returns by reference?
>>>
>>> function &foo(): noreturn {}
On Mon, 15 Mar 2021 at 09:36, Nikita Popov wrote:
> I'm not sure I follow your point. The fact that something is compatible,
> does not mean that you can just blindly perform a forwarding call. For
> example, consider this:
>
> class A {
> public function method(string $x) {}
> }
>
> class B
On Sun, 14 Mar 2021 at 18:09, Rowan Tommins wrote:
> Are you saying that having the parent::getSomeInt() call fail would be
> problematic?
>
>
Yes, that's where this becomes unsound – you can call the child method
statically, but the parent call assumes a dynamic instance.
This is just my persp
On Sun, 14 Mar 2021 at 12:02, Gert de Pagter wrote:
> Hey Internals,
>
> Recently i've been working on an older code base, where we have a lot
> of classes with all
> static methods. We've been moving to injecting the classes, and
> calling the methods as if they
> were not static.
>
> I wanted t
On Wed, 10 Mar 2021 at 16:04, Kamil Tekiela wrote:
> I am concerned with some edge cases. What if a function both returns and
> throws at the same time? For example:
>
> function a():noreturn {
> return throw new Exception('Boom!');
> }
>
> or
>
> function a():noreturn {
> try {
> throw new E
On Wed, 10 Mar 2021 at 13:55, Rowan Tommins wrote:
> I am however slightly confused by what exactly the implementation
> checks, and when. Is it actually looking for "exit" and "throw" statements?
>
No. Any function annotated with `: noreturn` causes the engine to insert
a ZEND_VERIFY_NORETURN_T
Hey,
Ondřej Mirtes and I present an RFC for the noreturn type:
https://wiki.php.net/rfc/noreturn_type
The feature already exists in Hack (the primary inspiration) and is
currently supported by our static analysis tools inside docblocks, and we
feel there's a good argument for it to be supported b
Thanks!
On Wed, 10 Mar 2021 at 11:30, Christoph M. Becker wrote:
> On 10.03.2021 at 16:54, Matthew Brown wrote:
>
> > Long-time internals lurker, first-time RFC creator & C coder.> > Could I
> get some karma please?
> Sure! RFC karma has been granted for mattbrown.
Hey!
Long-time internals lurker, first-time RFC creator & C coder.
Could I get some karma please?
Best wishes,
Matt
On Tue, 23 Feb 2021 at 06:21, Nikita Popov wrote:
> Another possibility would be to recognize T_ENUM in the lexer, but only if
> it is followed by whitespace and an identifier. This would possibly be
> friendlier for tooling using token_get_all(). It would not permit comments
> in between the tok
15 Feb 2021 at 15:06, Rowan Tommins wrote:
> On 15/02/2021 14:52, Matthew Brown wrote:
> > The most comparable example is between namespace separators:
> >
> > Ns \ bar();
> > Ns \ SOME_CONST;
> >
> > are both syntax errors.
>
>
> As Sara says, this o
On Mon, 15 Feb 2021 at 11:05, Sara Golemon wrote:
> That change was made very recently (8.0) and was done for technical
> reasons (attributes) not aesthetic ones.
>
> Personally, I agree that adding whitespace around double colon is a
> suspect move, but breaking valid code for the sake of one's
There are plenty of places where PHP doesn't allow whitespace currently.
The most comparable example is between namespace separators:
Ns \ bar();
Ns \ SOME_CONST;
are both syntax errors.
`MyClass::bar()` and `MyClass::SOME_CONST` are often used in place of
`Ns\bar()` and `Ns\SOME_CONST` because
Hey all,
Is there interest in prohibiting whitespace around double colons in the
next major PHP version?
I was surprised to learn that PHP treats :: similar to ->, allowing double
colons like
A::
b();
Looking at the top 2,000 packages in Packagist I can't find any evidence of
people using a dou
This proposal is interesting, and I see why the enum proposal makes it
useful.
Supporting this will mean a small amount of work for me (assuming it
passes) and other static analysis tools, but I don't want that to factor
into anyone's decision.
I am curious, though, whether the scope of this RFC
>
> > or https://psalm.dev/ (open source) are projects in that area
> > (Matthew Brown is one of the authors of Psalm)
> >
> I don't like the idea of executing that on www.php.net for a few reasons,
> but someone else mentioned the possibility of donated cpu time
W/r/t the goals:
– Promote the release of PHP 8 to the PHP developers
> – Promote PHP as a modern language, as well as the PHP 8 release, to the
> general tech audience
The page's design does a *great* job of promoting PHP 8 to existing PHP
developers, but a general tech audience skeptical of PH
I think the addition of runtime-erased generics would be a good thing for the
language.
I don’t think PHP should perform any sort of checking of generic parameters at
compile time. No other equivalent interpreter performs those compile-time
checks, and it’s also *very* complex — since adding su
> On Sep 17, 2020, at 3:25 PM, Levi Morrison
> wrote:
>
>
>>
>> On Thu, Sep 17, 2020 at 1:00 PM Matthew Brown
>> wrote:
>>>> On Sep 17, 2020, at 1:28 PM, Brent Roose wrote:
>>> But I don't want to get stuck on phrasing, if elidiing
> On Sep 17, 2020, at 1:28 PM, Brent Roose wrote:
>
> But I don't want to get stuck on phrasing, if elidiing is the right term as
> Larry suggests, let's go with it!
No, the correct term is “type erasure”:
https://en.m.wikipedia.org/wiki/Type_erasure
Its opposite is called reification:
https:
Quick thing before I get into my own reaction:
Transpiling is normally thought of as the process of converting one
language into another. Tools like Babel transpile TypeScript to JavaScript.
What's being proposed here (AFAICT) is type erasure – the generic type
information would be erased during
This would be a fantastic addition, and it would also alleviate an issue in
static analysis land where it's very tricky (in the general case) to verify
exactly what implications successfully completing a given foreach loop has
on the array being iterated over (e.g.
https://github.com/vimeo/psalm/is
On Thu, 20 Aug 2020 at 01:42, Sergey Panteleev
wrote:
> Hi, Benjamin,
>
> I think Nikita's suggestion is suitable for these purposes:
> https://github.com/php/php-rfcs.
>
> At the moment this is an experimental repository, but in this case, it
> will be quite possible to get feedback from the com
>
>
> I don't see how that would happen. What non-pathological case would allow
> for $foo && !$foo == true?
>
>
I suppose something a little less pathological would be
`$collection && $collection->pop() && !$collection`
which is still pretty icky (to me at least).
The other implication is that
On Tue, 14 Jul 2020 at 19:59, Josh Bruce wrote:
> Implement an interface and magic method to allow objects to represent
> false (or empty) while still be valid instances of the custom object (type).
>
> https://wiki.php.net/rfc/objects-can-be-falsifiable <
> https://wiki.php.net/rfc/objects-can-b
> I do not see a point in soft reserving something we don't even know if
> it will make it into 8.x.
An enum implementation seems like something that almost certainly will make it
into the language in the next 4 years, given PHP’s gradual adoption of features
that already exist Hack (e.g. att
This would break quite a lot of existing code, though PHP could add an
explicit keyword like "inout" that catches this behaviour (see example in
Hack: https://docs.hhvm.com/hack/functions/inout-parameters).
Today these issues can also be caught with static analysis:
https://psalm.dev/r/1f670956ab
>
> How much would you like/be adverse to a rector rule that changes `mixed`
> into a long union type (without `resource` in it)?
> Considering above posts, `mixed` is effectively
> `null|bool|string|int|float|array|object|resource`,
>
At runtime those things are effectively the same, but in th
1 - 100 of 371 matches
Mail list logo
