Null Coalescing expressions should handle `<uninitialized>`

[TwitchBronBron]

Proposal

Enhance the null coalescing operator to also check for <uninitialized>. Either invalid or <uninitialized> will result in the alternate being selected. Example:

thing = notDefined
result = thing ?? "default"

Will now transpile to:

thing = notDefined
result = thing
if type(thing) = "<uninitialized>" or thing = invalid
    result = "default"
end if

Justification:

Developer intent for null coalescing is to pick an alternate value if the consequent value is not defined. invalid and <uninitialized> both represent this concept of "not defined", and as such, we can produce safer code while maintaining the intent behind null coalescing.

Example:

thing = notDefined
result = thing ?? "default"

In the current releases of BrighterScript, this throws an exception when comparing thing (which is <uninitialized>) to invalid

Questions:

• should this be considered a breaking change or a bugfix? (i.e. should this only be added to v1, or can we also add to v0)

[addison-adler]

Since the alternative crashes I'd say this could be considered a bugfix
(if it didn't crash and instead permitted unplanned usage, I'd say breaking change)

[addison-adler]

Also I really like this change!

As much as I want to say "never use undefined variables" because I personally pay attention to the Problems tab and never allow them.. when working on a team, that just isn't always the reality of what code ends up getting pushed in. I also think its just good practice for utils/libs to protect against this scenario (my own type utils always protect against it instead of crashing)