On Wed, Sep 19, 2018 at 2:38 PM Rowan Collins <rowan.coll...@gmail.com> wrote:
> On Tue, 11 Sep 2018 at 08:05, Bob Weinand <bobw...@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
