Skip to main content

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.


Cheers!

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

Popular posts from this blog

Dart in 2016: The fastest growing programming language at Google, 2nd fastest growing in TIOBE Index

Dart was the fastest growing programming language at Google in 2016 with millions of lines of code written. It also made it to TIOBE Index Top 20 this month (see TIOBE's methodology).

It takes time to build something as ambitious as Dart and, in some ways, Dart is still in its infancy. But we're glad the hard work is starting to pay off.

Many thanks to our amazing community!

We're going to celebrate by ... releasing 1.22 next week (as per our usual 6 week release schedule).

AngularDart is going all Dart

Until now, the multiple language flavors of Angular 2 were written as TypeScript source, and then automatically compiled to both JavaScript and Dart. We're happy to announce that we’re splitting the Angular 2 codebase into two flavors – a Dart version and a TypeScript/JavaScript version – and creating a dedicated AngularDart team.

This is amazing news for Dart developers because:

The framework will feel more like idiomatic Dart.It will make use of Dart features that couldn't work with the TypeScript flavor. It will be faster.
This is equally great news for our TypeScript and JavaScript developers, by the way. Cleaner API, performance gains, easier contributions. Read more on the Angular blog.

Angular 2 for Dart is used by many teams at Google. Most famously by the AdWords team, but many other Google teams build large, mobile-friendly web apps. Some of the top requests from these teams were: make the API feel like Dart, provide a faster edit-refresh cycle, and improve applicat…

The new AdWords UI uses Dart — we asked why

Google just announced a re-designed AdWords experience. In case you’re not familiar with AdWords: businesses use it to advertise on google.com and partner websites. Advertising makes up majority of Google’s revenue, so when Google decides to completely redo the customer-facing front end to it, it’s a big deal. The Dart team is proud to say that this new front end is built with Dart and Angular 2. Whenever you asked us whether Google is ‘even using Dart for anything,’ this is what we had in mind but couldn’t say aloud. Until now. We asked Joshy Joseph, the primary technical lead on the project, some questions. Joshy is focusing on things like infrastructure, application latency and development velocity, so he’s the right person to ask about Dart.Q: What exactly did we launch on Monday?It’s a complete redesign of the AdWords customer experience that is rolling out slowly as a test to a small initial set of advertisers. The most noticeable thing is probably the Material Design look and f…