> > Are you proposing to deprecate the implicit `= null` default initializer > > for untyped properties? > > Yes. > > > > Thanks for the recap. For untyped properties, that's the historical > > behavior. For typed properties, that's explained in > > > https://wiki.php.net/rfc/typed_properties_v2#uninitialized_and_unset_properties > > *. What's the issue? > > The issue is that for new users, saying "that's the historical > behaviour, you just have to learn it" is not very helpful. > > > > * "If a typed property is `unset()`, then it returns to the uninitialized > > state. While we would love to remove support for the unsetting of > > properties, this functionality is currently used for lazy initialization > by > > Doctrine, in combination with the functionality described in the > following > > section." > > I think both you and Mark misunderstood my point in bringing this up - > I'm not complaining about the ability to call unset(), I'm complaining > that it behaves differently depending how the property was declared. > > Look at how the untyped property behaves in this example: > https://3v4l.org/nClNs The property disappears from var_dump(), but is > not actually deleted from the object, as seen by it still being private > when assigned a new value. Given that we have the magic "uninitialized" > state, and we're proposing to make reading an unset property an error, > it would make more sense for it to show as '["untyped":"Foo":private] => > uninitialized(mixed)' >
Understood (also https://3v4l.org/DgXJl ). Maybe start a new thread? (this one is not shown on externals.io, only findable via search) -- Guilliam Xavier
