(Dart) Support Dart's new Null Safety type system

[srawlins]

Describe the issue

Dart's new Null Safety language feature introduces some new keywords and a new way to specify types:

• late and required are new keywords

• Never is a new type found in dart:core

• (almost) all types can be suffixed with a ? to indicate a nullable type. For example, in:

  f(int x) { ... }
  g(int? x) { ... }

  f is a function which accepts a non-null int parameter, and g accepts a nullable int parameter.

Which language seems to have the issue?

Dart.

Are you using highlight or highlightAuto?

Either.

Sample Code to Reproduce

late int x;
f({required int? y}) {}
const List<Never> z = [];

Expected behavior

late and required should be highlighted as keywords. int? should highlight the same as int. Never should be highlighted like the other built-in types.

Additional context

[joshgoebel]

Please add a usage of Never to your sample.

A PR would be welcome. Tagging this as beginner friendly.

[srawlins]

Should the long list of built-in types just be duplicated to include, e.g. int?, String?, ... or is there a better way?

[joshgoebel]

Duplication is probably best, but you can do it dynamically with JS... break out the types (or do all the Built-Ins count?) split them, then build a second set with ? appended, add that to the first...

[joshgoebel]

You'll need to add ? to the keyword $pattern... and is that going to cause any false positives with ternary?

[joshgoebel]

Does this apply to user types as well? Is so might want to think about making it a mode instead that matches all [identifier]?, but again would need to consider false positives.

[srawlins]

Please add a usage of Never to your sample.

Done.

You'll need to add ? to the keyword $pattern... and is that going to cause any false positives with ternary?

It shouldn't; most Dart code is auto-formatted so that a ternary ? has whitespace before it.

Does this apply to user types as well? Is so might want to think about making it a mode instead that matches all [identifier]?, but again would need to consider false positives.

It does, but I think it would be more confusing to match [identifier]?, since that would match differently from [identifier].

Although... it is exceedingly common practice to only name types with a leading capital letter (and optional _) and to only name variables, consts, fields, methods, etc with a leading lower case letter (and optional _); so that might be a nice improvement to make...

[joshgoebel]

[identifier]?, since that would match differently from [identifier].

Not sure what you mean? If the pattern was [upper][a-z_whatever][possible ?] then you'd probably mix it all together into one mode. Then you'd only need to hard code lowercase types...

Although you have to be careful because modes eat content while keywords do not (keywords can match inside mode begin/end text, other modes cannot). That might not matter for Dart though. It seems to have a very simple grammar.

[joshgoebel]

@srawlins Any interest in taking a pass at the second part of this?

[srawlins]

Sorry, I dropped the thread here. I was getting at the idea that today we don't have any special mode for "types" that would include user types. For example:

int v1;
UserType v2;

int is in the list of built_ins in KEYWORDS, but UserType is not, and it matches no other mode. So int is highlighted as hljs-built_in, and UserType is not highlighted at all.

I think this is a fine. If user types should be highlighted separately from, say, functions and variables (e.g. display UserType and v2 in two different ways), that's fine, but I don't think it would be required to close this issue.

I can mail a PR adding int? etc to the list of built_ins.