What's the status of NNBD (and Strong Mode)?

[Danny Tuppeny]

There are a bunch of cases on GitHub relating to non-null by default, but they don't seem to have had any activity in over a year :(

Is any effort going into this? Not being able to opt-out of nulls is my biggest gripe with basically every language ever. Typescript now has it (along with a bunch of other great stuff, like union types and a type checker that narrows a union type based on the code)..

Also; is Strong Mode now "done" or still experimental? I found this page but not much more; so it's hard to tell where it's at.

Thanks!

[Mark Nordine]

I, too would love to know if any work has been done on NNBD. I think it would be a great language feature to have.

[Bob Nystrom]

On Thu, Jul 21, 2016 at 9:34 AM, Danny Tuppeny <da...@tuppeny.com> wrote:

There are a bunch of cases on GitHub relating to non-null by default, but they don't seem to have had any activity in over a year :(

Heh, my initial proposal is from 2011: http://journal.stuffwithstuff.com/2011/10/29/a-proposal-for-null-safety-in-dart/ :-/

 

Is any effort going into this?

Right this second, no.

 

Not being able to opt-out of nulls is my biggest gripe with basically every language ever. Typescript now has it (along with a bunch of other great stuff, like union types and a type checker that narrows a union type based on the code)..

Yeah, there's a lot of really neat stuff in TypeScript. I wish we done a bunch of it first.

 

Also; is Strong Mode now "done" or still experimental?

This is a great question.

Over the past several months, many on the team have been focused on getting strong mode and DDC production-ready and migrating as much existing code to be strong mode clean as possible. I believe the majority of code inside Google is now strong mode clean and is being analyzed with strong mode enabled.

We've gotten a ton of feedback from users and it's almost all positive. (Not exactly a surprise to the people who created strong mode in the first place, but a very nice confirmation.) Given that, I wouldn't say it's an experiment anymore. I think almost the entire team is convinced that strong mode is where it's at.

At the same time, it's not done. We are still tweaking the type rules. One of the things that's really difficult about adding a stricter type system later is keeping existing corpuses happy and minimizing user pain. So the first release of strong mode wasn't as strong as we might like. For example, it still allows implicit downcasts, and implicit casts from dynamic. As we get more and more code strong mode clean, we can gradually tighten those type rules to something closer to a conventional static type system.

The end goal is not to get to a language that statically guarantees no type errors with zero runtime checks, because that isn't practical in an object oriented language. (In Java, C#, etc. explicit casts can fail at runtime.) But it would be good to get to a point where it's pretty clear to a user where one of those errors might occur and give them confidence in the type safety of their code outside of those regions.

We are making a lot of progress on this. Once the basic foundation of strong mode is stable, there's a list of type system additions we want to investigate. Non-nullable types is, I think, the first one we will investigate.

Cheers!

– bob

[Danny Tuppeny]

Is any effort going into this?

Right this second, no.

That is super-specific, how about this month? ;P

Yeah, there's a lot of really neat stuff in TypeScript. I wish we done a bunch of it first.

Better late than never. TS is open source and compiles to JavaScript; you can probably just copy/paste theirs and tweak it; be done in an afternoon!

 

(Strong mode... <Snip>)

 

We are making a lot of progress on this. Once the basic foundation of strong mode is stable, there's a list of type system additions we want to investigate. Non-nullable types is, I think, the first one we will investigate.

Thanks for all the info! Shame about NNBD but the strong mode stuff sounds positive, especially if non-nulls might follow on.

I remembered there was another dealbreaker with Dart for me... no deserialisation of JSON (!)... maybe I can live with the nulls if that works better now - seems the new build/source_gen stuff might address this, I'll have to have a play...

But really; all I want is a nice portable language that runs on Windows, ChromeOS and Linux (x86 and ARM), runs in all browsers, can be used to build native Android apps, has strong type guarantees, can deserialise JSON and has no concept of nulls. Is that really so much to ask? :P

[Don Olmstead]

And a unicorn. Don't forget the unicorn.

--
For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups "Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

[Bob Nystrom]

On Thu, Jul 28, 2016 at 12:14 PM, Don Olmstead <don.j.o...@gmail.com> wrote:

And a unicorn. Don't forget the unicorn.

Unicorns are on the roadmap, though they are currently blocked on ponies and magic. Once we have the latter two, unicorns should be a straightforward addition.

– bob

[Don Olmstead]

Replace unicorns with Union Types and magic with NNBD and thats a nice roadmap. Ponies already exist.

[kc]

On Thursday, July 21, 2016 at 8:54:29 PM UTC+1, Danny Tuppeny wrote:

But really; all I want is a nice portable language that runs on Windows, ChromeOS and Linux (x86 and ARM), runs in all browsers, can be used to build native Android apps, has strong type guarantees, can deserialise JSON and has no concept of nulls. Is that really so much to ask? :P

Why not? This is exactly what Google needs. A modern language that comes between Java/C# and JS which is fast, secure and expressive, and  runs on the major modern hardware and software platforms (either directly or via transpilation).

Dart 1.x didn't come off because it wasn't ambitious enough (mobile!) and Google didn't seem to have it's weight behind it.

K.