Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103197
MIME-Version: 1.0
References: <AM0PR0702MB3684F2B7EFF1826F515BA940E2040@AM0PR0702MB3684.eurprd07.prod.outlook.com>
 <CALKiJKqgM=YsyqodP-4QNL52q8L05ZZxUD8iyGk9L+O9c9m1+w@mail.gmail.com>
In-Reply-To: <CALKiJKqgM=YsyqodP-4QNL52q8L05ZZxUD8iyGk9L+O9c9m1+w@mail.gmail.com>
Date: Thu, 20 Sep 2018 12:58:09 +0200
Message-ID: <CAF+90c8He-6M_WAKj7B_+fcgJhos+DPQ07afjmGyoNgx7RzE7g@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000cb434805764b66f8"
Subject: Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000cb434805764b66f8
Content-Type: text/plain; charset="UTF-8"

On Wed, Sep 19, 2018 at 2:38 PM Rowan Collins <rowan.collins@gmail.com>
wrote:

> On Tue, 11 Sep 2018 at 08:05, Bob Weinand <bobwei9@hotmail.com> wrote:
>
> > Hey,
> >
> > As announced, we are starting the vote on typed properties today.
> >
> > The voting period is two weeks, until sometime in the evening on Tuesday
> > 25-09-2018.
> >
> > Please find the RFC at https://wiki.php.net/rfc/typed_properties_v2.
> >
>
>
> For the record, I still think we will come to regret allowing non-nullable
> type hints without any constraint on the author of the class to initialise
> them correctly. As proposed, the invalid state may only be detected when it
> causes a runtime error in completely unrelated code.
>
> I gather that the authors of C# are currently going through a painful
> development phase to introduce better support for non-nullable types, and
> having to include many compromises and handle many edge-cases because it
> was not done earlier. I realise this case is not completely comparable, but
> we have an opportunity to get this right first time, and not just take the
> easy option.
>
> I am therefore going to make one last plea: if we don't yet know how to
> assert that complex types are initialised, do not allow them to be
> non-nullable in the first version of this feature.
>
> That is, allow `class Foo { public ?Foo $foo = null; }`, but not `class Foo
> { public Foo $foo; }`.
>
> This would still be a huge improvement to the language, but leaves us free
> to design additional features to prevent Unitialized Property Errors
> becoming as hated as Null Pointer Exceptions in Java or C#.


I am sympathetic to the wish of reporting initialization errors during
construction rather than at the use-site. However, there is no clear
proposal on how this will be reconciled with other requirements that we
have, such as support of uninitialized properties for lazy initialization,
etc.

I do not consider it advisable to require a null initialization as a "first
iteration" of the proposal. Regardless of what our intention might be, the
effect of such a restriction will not be "I'm not going to type this
property for now, because non-nullable types are not supported", it's going
to be "I'll give this a nullable type even though it isn't, because that's
better than no type at all." Use of nullable types where they are not
necessary would be a disastrous outcome of this proposal.

To move this discussion forward in a productive direction, we need a
concrete, detailed proposal of how enforcement of initialization should
work, while being compatible with secondary requirements. I believe it goes
without saying that we cannot change the typed properties RFC in such a
substantive way at this point in time. However, if you or someone else can
bring forward an RFC that specifies the precise semantics of initialization
checks as you envision them and which is endorsed by maintainers of
libraries with special initialization requirements, then we still have a
lot of time to discuss and incorporate such a proposal before typed
properties ship in PHP 7.4.

Thanks,
Nikita

--000000000000cb434805764b66f8--