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).

A stronger Dart for everyone

We are constantly asking ourselves:
How do we make developers even more productive when writing Dart apps? We believe that a critical part of the answer to this question is to make strongmode – a sound static type system for Dart – the standard for all Dart developers.

Teams that use Dart to build apps like Soundtrap, AdWords, AdSense, and Greentea say they really enjoy using strong mode features, such as early error detection. In fact, teams that have switched completely to strong mode cite not only early error detection but also better code readability and maintainability as major benefits. We hear this both from small teams and – even more so – from large teams with hundreds of developers writing and maintaining millions of lines of Dart code. As Björn Sperber from Soundtrap says,
Strong mode and the smooth integration with IntelliJ is a joy to use and a huge improvement. If you’ve tried out Flutter, you’ve already used strong mode checks from the Dart analyzer.

Given the benefits …

AngularDart 3.0: Easy upgrade, better performance

AngularDart 3.0 is now available. It brings better performance and smaller generated code, while also making you more productive.


Version 3.0 is an evolution: although it has some breaking changes (detailed below), it is a smooth upgrade due to minimal public API adjustments. Most of the progress is under the hood—in code quality, stability, generated code size, performance, and developer experience.

Code quality:
2731 instances of making the framework code more type safe (using sound Dart).The AngularDart framework code size is down by 12%.Many additional style updates to the codebase:Changed to use idiomatic <T> for generic methods.Removed NgZoneImpl, all the code exists in NgZone now.Stability:
Many CSS encapsulation fixes due to update with csslib package.Fixed bugs with IE11.

Performance:
For the Mail sample app, we see 30% faster time-to-interactive (currently 3812 ms on a simulated 3G connection, measured via Lighthouse).Our large app benchmark shows 2x faster render times of…