On Sat, May 18, 2024 at 4:41 PM Rowan Tommins [IMSoP] <imsop....@rwec.co.uk> wrote: > > On 18/05/2024 11:52, Luigi Cardamone wrote: > > Are there any downsides in adding a > > specific syntax to check if a property > > is initialized with any value? > > In my opinion - and I stress that others may not share this opinion - > the entire concept of "uninitialized properties" is a wart on the > language, which we should be doing our best to eliminate, not adding > more features around it.
I fully agree. The reason NULL was deemed the "billion-dollar mistake" is not because NULL isn't a useful value, it's because it is implicitly part of types that are commonly never NULL. For example, in C, there's no way through the type system to convey whether a pointer returned from a function may or may not be NULL (ignoring hints through attributes). As such, the user must look at documentation (which may be inaccurate), or even guess whether NULL must be handled. A failure to do so will not result in any compilation errors, but crashes at runtime. Luckily, PHP does not suffer from this issue. null is only allowed when the type says so. However, if you leave your class properties uninitialized, you're essentially recreating this issue. How do you know whether it is safe to access class properties? May they be uninitialized under certain conditions? The type system has no way of conveying this information. There's no way to know, without looking at the implementation. Static analysis won't be able to catch it for you either. So, as Rowan suggested, it is better to hint at this "uninitialized" value that must be handled through the type system, currently most conveniently through single-case enums and union types. Ilija
