Skip to content
This repository has been archived by the owner on Jul 19, 2019. It is now read-only.

Nullability in typings is wrong #38

Open
mihe opened this issue May 8, 2019 · 0 comments
Open

Nullability in typings is wrong #38

mihe opened this issue May 8, 2019 · 0 comments
Assignees
Labels
enhancement New feature or request

Comments

@mihe
Copy link
Owner

mihe commented May 8, 2019

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.

@mihe mihe added the enhancement New feature or request label May 8, 2019
@mihe mihe self-assigned this May 8, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant