Notes from the April 22 Dart Language Design Meeting

Once again, the ever-helpful Bob Nystrom fills us in on the language design discussions taking place amongst Dart engineers. Here are his notes from the April 22 language meeting:

elvis operator / safe navigation operator

Lars is fine with the idea of adding some syntactic sugar like this if it helps real users. Kasper thinks we should wait until after 1.0 to look into it since we'll need analyzer support, editor support, tests, etc.

Lars is worried about a safe navigation operator because he thinks it would be strange if people started using it everywhere.

The current plan is to wait until after 1.0 and then discuss it again.

unique library names

Kasper has an idea to ensure that library names are unique when packages are published on pub. He wants to make it easy for users to give unique names, so the easy idea is to use the package name as a prefix.

I mentioned that validating this at publish is the least user-friendly time to do this. Something in the editor would be less painful. I asked what value the user gets in return for having to enter a unique name for each of their libraries.

Gilad says: "Composability."

Kasper says its useful for the same reason we have 'part of': it makes it easier to see how the library fits into the program hierarchy.

Lars says it helps users track down errors where they've imported the same library from multiple URLs. It also helps with reflection, since the reflective API takes a library name as a key, you need a unique name to get a single library back.

According to Gilad, though, that API changed recently to identify libraries by URL. But library names are better for error-reporting, etc.

Kasper will put together an email for the language team with his proposal.

recursive types

Johnni mentioned we have recursive types for some typedef stuff.

Gilad says that's probably true, but we have some restrictions on them so they are probably meaningful.

[There was some discussion on the team about this point afterwards, so this may not be a settled point.]

question mark operator

Gilad isn't sure why we can't get rid of it. Almost all uses of it are in dart:html and those folks say we can get rid of it.

Lars thinks it's a nice addition to the language, but if it's not used and adds complexity, we can take it out. He wonders what the migration process would look like.

I will discuss it with the dart:html folks and see what they think.

super in constructors

According to Gilad, the VM team says allowing the super() in any position costs some performance. The only location that makes sense is after initializers and before the body. He always thought it should be at the end.

Lars says the initializer syntax is just a comma-separated list, so it seems a little wierd to have a warning if super is not at the end. Is the perf problem just a deficiency in the current impl?

Gilad isn't sure. He'll talk to Ivan.

Kasper says he likes seeing super() at the beginning. He usually finds it harder to read at the end, especially if there's many initializers.

[For what it's worth, the style guide says to put them at the end.]

Cheers!

As always, view the changelog for the full list of changes, and to get started with the Editor, see our tutorial.