Hi Sara,
> While it's certainly silly/pointless to have a nil constructor when
there are non-promoted args present, I think that deliberately making
that mode special (read: inconsistent) is the wrong way to go.
Sorry, but I don't follow - so you would prefer that this:
public function __construct();
be valid syntax as well, considering within the scope of the proposed?
Am I reading this right?
- Matīss
On Tue, May 11, 2021 at 09:33, Sara Golemon <poll...@php.net> wrote:
On Tue, May 11, 2021 at 5:18 AM Matīss Treinis <mrtrei...@gmail.com
<mailto:mrtrei...@gmail.com>> wrote:
> Yes, just to clarify the scope of my initial proposal, this should
only
> ever apply to promoted constructors that have 1 or more promoted
> parameters, and no not-promoted parameters.
>
Hard disagree. While it's certainly silly/pointless to have a nil
constructor when there are non-promoted args present, I think that
deliberately making that mode special (read: inconsistent) is the
wrong way to go.
> These would NOT be considered valid:
> public function __construct();
>
For example, Niki's reply showed a place where that mode is perfectly
reasonable (singleton finals). If you must have this syntactic
sugar, then please make it consistent.
> as well as anything not related to __construct.
>
I'd be willing to go along with inconsistency since once you allow
syntax you can't unallow it without pain. So while I don't love the
tack, I'll follow it if we do this feature. (which IMO we shouldn't).
On Tue, May 11, 2021 at 8:59 AM Matīss Treinis <mrtrei...@gmail.com
<mailto:mrtrei...@gmail.com>> wrote:
> If there are no super strong arguments on why this should not
happen or go
> to RFC, I will draft a RFC and from there, the usual process
applies.
>
I think you've heard a number of strong arguments why it should not
happen, but I also think this deserves its chance to be fleshed out
and voted on, so by all means, do work the RFC.
-Sara
