Dart 2.0

[Jacob Goodson]

Dart 2 is on the horizon, at this point, what considerations are being made for inclusion?  Of course, I suppose the Dart team could delay Dart 2 inevitably by making innumerable, interim, incremental updates.

[Bob Nystrom]

On Mon, Oct 27, 2014 at 10:00 AM, Jacob Goodson <submissio...@gmx.com> wrote:

Dart 2 is on the horizon, at this point, what considerations are being made for inclusion?

What makes you say it's on the horizon? Our version numbering scheme doesn't by necessity go from 1.9 to 2.0. The natural version after 1.9 is 1.10. :)

- bob

[Jacob Goodson]

I just like getting the scoop on alpha features =).

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

[Matthew Butler]

I'd say current Alpha features are async/await and enums. Async/await is almost beta though now?

2.0 need only come if there's a breaking change to the language or to the core libraries. Otherwise features (like those mentioned above) can be added without breaking functionality and are a minor version number increase.

If you really want to see the latest and greatest being added to the language, tools and libraries you can always watch the commit change logs. I usually watch it throughout the day and see what interesting tidbits are coming in.

https://code.google.com/p/dart/source/list

Matt

[Günter Zöchbauer]

There was mentioned that Future should be moved to core. This would be a breaking change.

What about the existing code, are there plans to add the async keyword on all async methods?

[Matthew Butler]

On Tuesday, October 28, 2014 12:04:36 PM UTC-3, Günter Zöchbauer wrote:

There was mentioned that Future should be moved to core. This would be a breaking change.

Actually, it sounds like they plan to export it from dart:core after importing it from dart:async. See Kasper's comment here:

https://plus.google.com/u/0/+KasperLund/posts/55D43amSHXj

Which would not make it a breaking change.

 

What about the existing code, are there plans to add the async keyword on all async methods?

I have no knowledge of this in fact, however I'd say it's unlikely that a mass rewrite just to accommodate the async/await keywords is unlikely. Perhaps as other changes/updates are made to a function it will simultaneously be converted to async but I wouldn't expect an entire rewrite just to make use of it.

That said, I know many parts of pub have already been rewritten to make use of the keywords simply to enable ease of further development in other areas.

Matt  

[Günter Zöchbauer]

I'm curious about how this will be handled. There is a big improvement possible for dev experience with the addition of async+await but if the core packages don't support it, the improvement will be limited. 
For hosted packages this should be less of a problem because most of them are pre 1.0.

[Lasse R.H. Nielsen]

On Tue, Oct 28, 2014 at 4:04 PM, Günter Zöchbauer <gzo...@gmail.com> wrote:

There was mentioned that Future should be moved to core. This would be a breaking change.

Actually not. It would just be adding one line to dart:core:

   export "dart:async" show Future, Stream;

(You'll want Stream too, as the return type of async* functions).

That shouldn't break anything.

We can't remove the Future type from dart:async, because *that* would be breaking.

 

What about the existing code, are there plans to add the async keyword on all async methods?

The "async" keywords not something you can just add, you need to rewrite the function body as well. 

Rewriting just to use async functions bodies is not a goal.

Code written or rewritten after async bodies have been implemented will use the feature if it makes sense, just as every other language feature.

I don't expect most current Future-returning functions to change in the near future, and many will probably never change (they work, don't fix them!)

Luckily the function signatures are unrelated to the use of async function bodies, so we can decide what to do on a case-by-case basis.

/L

 

On Tuesday, October 28, 2014 1:24:22 PM UTC+1, Matthew Butler wrote:

I'd say current Alpha features are async/await and enums. Async/await is almost beta though now?

2.0 need only come if there's a breaking change to the language or to the core libraries. Otherwise features (like those mentioned above) can be added without breaking functionality and are a minor version number increase.

If you really want to see the latest and greatest being added to the language, tools and libraries you can always watch the commit change logs. I usually watch it throughout the day and see what interesting tidbits are coming in.

https://code.google.com/p/dart/source/list

Matt

On Monday, October 27, 2014 5:56:48 PM UTC-3, Jacob Goodson wrote:

I just like getting the scoop on alpha features =).

On Mon, Oct 27, 2014 at 4:09 PM, 'Bob Nystrom' via Dart Misc <mi...@dartlang.org> wrote:

On Mon, Oct 27, 2014 at 10:00 AM, Jacob Goodson <submissio...@gmx.com> wrote:

Dart 2 is on the horizon, at this point, what considerations are being made for inclusion?

What makes you say it's on the horizon? Our version numbering scheme doesn't by necessity go from 1.9 to 2.0. The natural version after 1.9 is 1.10. :)

- bob

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

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

To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

--
Lasse R.H. Nielsen - l...@google.com  

'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 København K - Denmark - CVR nr. 28 86 69 84

[Lasse R.H. Nielsen]

On Tue, Oct 28, 2014 at 4:34 PM, Günter Zöchbauer <gzo...@gmail.com> wrote:
>
> I'm curious about how this will be handled. There is a big improvement possible for dev experience with the addition of async+await but if the core packages don't support it, the improvement will be limited. 

It makes absolutely no difference to the user whether a function that returns a Future is written in the "classical" way, or using an async function body.
It's not something core packages have to be rewritten to support. They should work fine as currently written.
/L

--
Lasse R.H. Nielsen - l...@google.com  
'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 København K - Denmark - CVR nr. 28 86 69 84

I'm curious about how this will be handled. There is a big improvement possible for dev experience with the addition of async+await but if the core packages don't support it, the improvement will be limited. 

[William Hesse]

Just to clarify, the async keyword on a function is not what indicates that the function is async, the fact that the function returns a future is what makes the function async.  The only reason to use the async keyword on a function is if you want to use "await" and similar keywords in the function's implementation (its body).

I would say there is no difference between 

Future foo(x)  {

  return bar(x).then((y) => y * y);

}

and 

Future foo(x) async {

  var y = await bar(x);

  return y * y;

}

, except that I think the second example, the async function body, always returns a future immediately, before even running bar, and running bar happens after the currently running function terminates and returns to the event loop.

William Hesse

[Bob Nystrom]

On Tue, Oct 28, 2014 at 8:45 AM, 'William Hesse' via Dart Misc <mi...@dartlang.org> wrote:

Just to clarify, the async keyword on a function is not what indicates that the function is async, the fact that the function returns a future is what makes the function async.  The only reason to use the async keyword on a function is if you want to use "await" and similar keywords in the function's implementation (its body).

By analogy:

Dart supports two ways of defining function bodies, using { ... } or => .... The choice between those is purely an implementation detail of the function and has no affect on its public API whatsoever. async is the same way.

Cheers!

- bob

[Günter Zöchbauer]

Thanks, great to hear!

So when a method/function returns a Future it can be used with await?

[Kevin Millikin]

On Tue Oct 28 2014 at 5:13:27 PM Günter Zöchbauer <gzo...@gmail.com> wrote:

Thanks, great to hear!

So when a method/function returns a Future it can be used with await?

Yes.  Any expression that evaluates to a future can be used with await:

await  (new Future.delayed(...))

An expression that evaluates to a non-future value can be used with await.

... await "done" ...

is the same as

... new Future.value("done") ...

An expression that throws can also be used with await.  It will allocate a future that throws.

[Filipe Morgado]

Await (and later async*) is a great feature! Can't wait to see it hit stability (and get in the spec).

And enums seem like they will be very handy.

But other stuff is going on ... jitted RegEx is a little sign that the Dart VM is approaching an excellence milestone.

Maybe getting ready to get first-class citizenship in AppEngine and Chrome?

Overall, congratulations Dart Team! Increasingly great language, increasingly great tools and increasingly great VM!

Now ...

We know what features are rolling out in the near future.

However, I would like to get back to the original purpose of this thread and discuss what features or improvements may be coming next.

We know that nothing is set in stone, but little hints on which direction the language (and the tools) may (or may not) go, would be welcomed.

Personal opinions as well, even if they don't affect the decision making process.

Personally, I would like to see some improvements (or comments) in the following areas:

• Mixins improvements (constructors would be nice)
  
• Protected members (or some way to safely simulate them)
• Transferable byte buffers (even if only server-side)
• non-nullable types (or unions) (I'm not really bitten by this but it would make APIs feel a lot safer)

My 2 cts :P

[Jacob Goodson]

I would like to know when chrome will be getting the Dart vm.  As of right now, the Chrome Dev Editor sucks if you are a Dart developer.