Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
srawlins opened this issue May 12, 2020 · 9 comments
Closed

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

srawlins opened this issue May 12, 2020 · 9 comments

Comments

@srawlins
Copy link
Contributor

@srawlins srawlins commented May 12, 2020

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
Copy link
Member

@joshgoebel joshgoebel commented May 12, 2020

Please add a usage of Never to your sample.

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

@srawlins
Copy link
Contributor Author

@srawlins srawlins commented May 12, 2020

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

@joshgoebel
Copy link
Member

@joshgoebel joshgoebel commented May 12, 2020

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
Copy link
Member

@joshgoebel joshgoebel commented May 12, 2020

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

@joshgoebel
Copy link
Member

@joshgoebel joshgoebel commented May 12, 2020

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
Copy link
Contributor Author

@srawlins srawlins commented May 12, 2020

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
Copy link
Member

@joshgoebel joshgoebel commented May 12, 2020

[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
Copy link
Member

@joshgoebel joshgoebel commented Jun 8, 2020

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

@srawlins
Copy link
Contributor Author

@srawlins srawlins commented Jun 9, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

2 participants