Currently only input reference parameters are nullable (i.e. marked as | null). This was added as a hack in order to allow null to be passed to function parameters while having strictNullChecks enabled.
This problem still applies to reference properties though, and with properties not being nullable you currently can't set them to null with strictNullChecks enabled.
The naive solution would be to simply make every reference property nullable as well. However, this makes them way too tiresome to work with, because you end up sprinkling non-null assertions and unnecessary if-statements all over your code. The biggest source of this comes from actor components also being marked as nullable, when in reality they will never be null (in Blueprint classes at least).
A more refined solution would therefore try to figure out if a reference property is in fact an actor component and leave out nullability. However, regular reference properties to actor components or references to actor component declared in C++ can't have the same non-null guarantee and would therefore still have to be nullable.
All-in-all it's messy whichever way you look at it, because the typings are generated from a type system that doesn't express nullability.
I'm leaning towards simply scrapping nullability from the typings entirely and discouraging the use of strictNullChecks.
Currently only input reference parameters are nullable (i.e. marked as
| null). This was added as a hack in order to allownullto be passed to function parameters while havingstrictNullChecksenabled.This problem still applies to reference properties though, and with properties not being nullable you currently can't set them to
nullwithstrictNullChecksenabled.The naive solution would be to simply make every reference property nullable as well. However, this makes them way too tiresome to work with, because you end up sprinkling non-null assertions and unnecessary if-statements all over your code. The biggest source of this comes from actor components also being marked as nullable, when in reality they will never be null (in Blueprint classes at least).
A more refined solution would therefore try to figure out if a reference property is in fact an actor component and leave out nullability. However, regular reference properties to actor components or references to actor component declared in C++ can't have the same non-null guarantee and would therefore still have to be nullable.
All-in-all it's messy whichever way you look at it, because the typings are generated from a type system that doesn't express nullability.
I'm leaning towards simply scrapping nullability from the typings entirely and discouraging the use of
strictNullChecks.