[PHP-DEV] Re: [RFC] New in initializers

Hi Nikita, Nikita Popov wrote: Hi internals, I would like to propose allowing the use of "new" inside various initializer expressions: https://wiki.php.net/rfc/new_in_initializers In particular, this allows specifying object default values for properties and parameters, and allows the use of o

Re: [PHP-DEV] Re: [RFC] New in initializers

On 06/03/2021 12:09, Andrea Faulds wrote: This seems reasonable, but I fear it would create a similar mess to C++ with static initialisers, because a class constructor can do basically anything… That was my initial reaction, too, but it's actually pretty trivial to do static initialisation

Re: [PHP-DEV] [RFC] Extend error control operator to suppress exceptions

On 05/03/2021 04:26, Mike Schinkel wrote: 1. What @ means and what it would look like in practice, 2. What catch(union_class_list) would look like in practice, 3. What @<\Throwable>expression means and what it would look like in practice, and 4. Can you provide a few concrete code examples, plea

Re: [PHP-DEV] [RFC] Extend error control operator to suppress exceptions

As Rowan has addressed your first points, I'll skip them but will add a code example to clarify in the RFC. On Fri, 5 Mar 2021 at 04:26, Mike Schinkel wrote: > > This proposal on it's own would not be sufficient to trigger such a > change > > for extensions but in combination with another propos

Re: [PHP-DEV] [RFC] Extend error control operator to suppress exceptions

On Thu, 4 Mar 2021 at 22:05, Rowan Tommins wrote: > On 04/03/2021 14:08, G. P. B. wrote: > > This new RFC which I'm proposing is to extend the capability of the error > > control operator @ to not just suppress diagnostic messages but also > > exceptions. > > It can currently be found on GitHub:

Re: [PHP-DEV] [RFC] Extend error control operator to suppress exceptions

On Thu, Mar 4, 2021, at 8:08 AM, G. P. B. wrote: > Hello internals, > > This new RFC which I'm proposing is to extend the capability of the error > control operator @ to not just suppress diagnostic messages but also > exceptions. > It can currently be found on GitHub: [1] > https://github.com/Gir

Re: [PHP-DEV] [RFC] Extend error control operator to suppress exceptions

On 06/03/2021 18:00, Larry Garfield wrote: My first thought is that if you're throwing away exceptions, you're therefore performing an expensive operation (generating a backtrace for the exception) that will then be discarded, and thus is wasted effort. I think regardless of any new syntax,

Re: [PHP-DEV] [RFC] Extend error control operator to suppress exceptions

> On Mar 6, 2021, at 10:30 AM, G. P. B. wrote: > > As Rowan has addressed your first points, I'll skip them but will add a code > example to clarify in the RFC. > > On Fri, 5 Mar 2021 at 04:26, Mike Schinkel > wrote: > > This proposal on it's own would not be suff

Re: [PHP-DEV] [RFC] Extend error control operator to suppress exceptions

> On Mar 6, 2021, at 1:00 PM, Larry Garfield wrote: > > On Thu, Mar 4, 2021, at 8:08 AM, G. P. B. wrote: >> Hello internals, >> >> This new RFC which I'm proposing is to extend the capability of the error >> control operator @ to not just suppress diagnostic messages but also >> exceptions. >> I

[PHP-DEV] [RFC] [Discussion] Adding return types to internal methods

Hi Internals, I've just finished the first iteration of the RFC ( https://wiki.php.net/rfc/internal_method_return_types) as well as the implementation based on the feedback Nikita and Nicolas provided. Thus, I'd like to start the discussion phase. Regards: Máté

Re: [PHP-DEV] Avoiding enum reserved keyword

Hi Nikita > 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 tokens though. Thanks for the suggestion. T