Support non-null assertion expression x!

[andy-hanson]

Adds support for TypeScript's x! non-null assertion expression. If x is of type T | null, this is equivalent to <T> x.
(Documentation: See "Type guards and type assertions" at in the TypeScript handbook)

This does not come with a runtime check for consistency with type assertions. See #234.

[dcodeIO]

cc @MaxGraey

[MaxGraey]

Great! We also discussed with @dcodeIO about new semantic meaning of exclamation operator for array's unchecked index access like write var item = arr![5] instead var item = unchecked(arr[5]).

btw @andy-hanson you should have received an invitation to our Slack chat.

[MaxGraey]

LGTM, except this PR should also handle this case:

class Foo { boo: i32 }
export function test2(foo: Foo | null): i32 {
  return foo!.boo;
}

Currently this fail

[dcodeIO]

Remains the question what we'll do with unchecked accesses then (what unchecked(...) currently does). Not sure that this can be combined in a good way, but this issue also makes clear that we should probably not use x! for that purpose anyway. @MaxGraey ?

[MaxGraey]

It is necessary to formalize how semantically an "unchecked case" will be handled in combination with non-null assertion. If you consider each case for array access, then you can get:

1). Array is non-nullable var arr: Array<T>:

• checked access as usual: arr[index];
• unchecked access: arr![index];

2). Array is nullable var arr: Array<T> | null:

• checked access as usual: arr![index];
• unchecked access: arr!![index] (double exclamation looks strange but valid in TS). Equivalent to unchecked(arr![index]);
• should throw compilation error: arr[index];

What do you think?

[MaxGraey]

Another variant for "unchecked" index access of array is arr[index!].

[dcodeIO]

Not a bad idea. That could work, on the index, as it should never be nullable anyway due to being an i32.

[andy-hanson]

as it should never be nullable anyway due to being an i32

See #233 -- IMO i32 | null should be a valid type and could be implemented by passing an i32 and boolean together. Otherwise how do you implement Map<T, i32>.get, or any other generic function returning T | null?

[dcodeIO]

There are some occasions in the sources where a .has is performed before a .get because of this (with .get resulting in unreachable if the value wouldn't exist). I haven't yet updated a lot of them. That's of course inefficient, because it involves two hash lookups on a match, but since there's no undefined we could use, I didn't see a good alternative. Maybe something like i32 | null could be modeled once the multi value spec lands (as an i32 and bool as you suggest).

[dcodeIO]

Sorry for not following up here. Wasn't quite comfortable with the implementation but couldn't tell why. Now implemented in #443 as another kind of assertion. Thank you anyway!