php-fig
New PHP 8.4 Syntax: new MyClass()->method() without parentheses
new Foo()->baz() will be allowed in PHP 8.4, we should cover it in the next version of PER-CS.
To me this is similar to the question of new Foo vs new Foo() where we decided the latter was better for readability: https://github.com/php-fig/per-coding-style/blob/master/spec.md#4-classes-properties-and-methods
What should we say here? "Favor using the non-parens version if you can", or is there more to say on the matter?
I'm of the opinion that it's simpler to see at a glance that a new instantiation is happening with wrapping parenthesis, but I don't think it's so much of an improvement that it justifies adding the wrapper in every situation.
Given that this is technically existing syntax, we'd need to go to 3.0 (or drop the thinking in #10) in order to add MUST NOT use parenthesis though we could require the opposite opposite since that's backwards compatible. In 2.1 we could add something like:
When chaining new instantiations with method calls (IE
new Foo()->baz(), the instantiation - including the new keyword - SHOULD NOT be wrapped in parenthesis. When dealing with a complex statement, wrapping parenthesis MAY be used for readability.
As usual, I don't think "never use this fancy new syntax that was just approved" is going to fly. The RFC passed 25 to 4. :-) So let's take "MUST NOT" use it off the table, as it's clear people want to use it.
The question is whether we encourage it, or stay silent. I'm leaning toward silent at the moment, but could be convinced otherwise. (We can always say something about it in a future version.)
As usual, I don't think "never use this fancy new syntax that was just approved" is going to fly. The RFC passed 25 to 4. :-) So let's take "MUST NOT" use it off the table, as it's clear people want to use it.
I agree, but I think you're misinterpreting my comment. I said "MUST NOT use parenthesis" which would mean we advocate for the thing that passed 25 to 4.
I'm saying that we cannot advocate stronger than a SHOULD until 3.0 unless we advocate for the thing that requires no code change, which I agree we shouldn't do.
I don't think "you must use this new syntax in this way" counts as a BC break. It would only be a BC break if existing code suddenly becomes non-compliant with a new version.