Discussion:
[dart-misc] Dart 2 Breaking Change Proposal: Disallow void returns from dynamic functions
'Leaf Petersen' via Dart Misc
2018-02-21 23:57:33 UTC
Permalink
TLDR: We are soliciting feedback on the proposal to disallow return a
`void` typed value from a function whose return type is not `void`.

The original Dart 2 proposal for the treatment of `void` attempted to
prevent `void` typed values from being accidentally used. See here for
details on the proposal: https://github.com/dart-lang/sdk/issues/30597 .
When we prototyped this proposal, we felt that some of the proposed
restrictions were too intrusive. We recently landed a subset of these
restrictions (announced on flutter-dev here:
https://groups.google.com/forum/#!topic/flutter-dev/scnh7SfYa_o). We are
proposing to add one additional restriction, based on our observation that
fixing code broken by the change is relatively benign, and that it has
essentially no impact on flutter framework code.

*What is the proposed change?*

In Dart 1, it was legal to return a `void` typed value from a function with
return type `dynamic`. This is occasionally done implicitly (where the
return type is left off the function) and only very infrequently done
explicitly.

```dart
void returnsVoid() {}

// Occasionally seen
implicitDynamic() => returnsVoid();

// Rare
dynamic explicitDynamic() => returnsVoid();
```

We are proposing to make both of these uses an error, and are soliciting
feedback from the community about the impact and desirability of these
changes.

*What should I do?*

If you are opposed to this change, either because you feel it's a bad
change, or because you feel that it will break too much of your existing
code, please provide feedback here, on the issue linked above, or to me
directly.

*What should I expect to happen next?*

If the sense of the community is that this change is worthwhile, we will
send a breaking change announcement and land the new restrictions. If the
overall sense is that catching these issues is not worth the breakage in
existing code, we will abandon this proposal.

Please feel free to reach out to me with questions or feedback.

thanks,
-leaf
--
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+***@dartlang.org.
Anatoly Pulyaevskiy
2018-02-22 00:08:26 UTC
Permalink
I have a feeling it might break a lot of code but as long as void => void
scenario still valid I think it's a good change.
By void => void I mean:

void returnsVoid() {}
void alsoReturnsVoid() => returnsVoid();

Would be interesting to see if (how often) I'm using dynamic => void in my
code.
Wondering if there is a lint (or flag) I can use currently in 2.0.0-dev
versions to check this?

On Wed, Feb 21, 2018 at 3:57 PM 'Leaf Petersen' via Dart Misc <
Post by 'Leaf Petersen' via Dart Misc
TLDR: We are soliciting feedback on the proposal to disallow return a
`void` typed value from a function whose return type is not `void`.
The original Dart 2 proposal for the treatment of `void` attempted to
prevent `void` typed values from being accidentally used. See here for
details on the proposal: https://github.com/dart-lang/sdk/issues/30597 .
When we prototyped this proposal, we felt that some of the proposed
restrictions were too intrusive. We recently landed a subset of these
https://groups.google.com/forum/#!topic/flutter-dev/scnh7SfYa_o). We are
proposing to add one additional restriction, based on our observation that
fixing code broken by the change is relatively benign, and that it has
essentially no impact on flutter framework code.
*What is the proposed change?*
In Dart 1, it was legal to return a `void` typed value from a function
with return type `dynamic`. This is occasionally done implicitly (where
the return type is left off the function) and only very infrequently done
explicitly.
```dart
void returnsVoid() {}
// Occasionally seen
implicitDynamic() => returnsVoid();
// Rare
dynamic explicitDynamic() => returnsVoid();
```
We are proposing to make both of these uses an error, and are soliciting
feedback from the community about the impact and desirability of these
changes.
*What should I do?*
If you are opposed to this change, either because you feel it's a bad
change, or because you feel that it will break too much of your existing
code, please provide feedback here, on the issue linked above, or to me
directly.
*What should I expect to happen next?*
If the sense of the community is that this change is worthwhile, we will
send a breaking change announcement and land the new restrictions. If the
overall sense is that catching these issues is not worth the breakage in
existing code, we will abandon this proposal.
Please feel free to reach out to me with questions or feedback.
thanks,
-leaf
--
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
--
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+***@dartlang.org.
Istvan Soos
2018-02-22 08:23:03 UTC
Permalink
Is there a language or tooling benefit of making this an error instead
of a linter hint (that is optional)?

The `implicitDynamic() => returnsVoid();` format is usually a
one-liner, while putting braces around it pushes it to three lines,
without much visible benefits otherwise. The effect is more
unfavourable when we are passing in a function closure (e.g.
Iterable.forEach).

It would be sad to lose the compact code without much upside.

Cheers,
Istvan


On Thu, Feb 22, 2018 at 12:57 AM, 'Leaf Petersen' via Dart Misc
TLDR: We are soliciting feedback on the proposal to disallow return a `void`
typed value from a function whose return type is not `void`.
The original Dart 2 proposal for the treatment of `void` attempted to
prevent `void` typed values from being accidentally used. See here for
details on the proposal: https://github.com/dart-lang/sdk/issues/30597 .
When we prototyped this proposal, we felt that some of the proposed
restrictions were too intrusive. We recently landed a subset of these
https://groups.google.com/forum/#!topic/flutter-dev/scnh7SfYa_o). We are
proposing to add one additional restriction, based on our observation that
fixing code broken by the change is relatively benign, and that it has
essentially no impact on flutter framework code.
What is the proposed change?
In Dart 1, it was legal to return a `void` typed value from a function with
return type `dynamic`. This is occasionally done implicitly (where the
return type is left off the function) and only very infrequently done
explicitly.
```dart
void returnsVoid() {}
// Occasionally seen
implicitDynamic() => returnsVoid();
// Rare
dynamic explicitDynamic() => returnsVoid();
```
We are proposing to make both of these uses an error, and are soliciting
feedback from the community about the impact and desirability of these
changes.
What should I do?
If you are opposed to this change, either because you feel it's a bad
change, or because you feel that it will break too much of your existing
code, please provide feedback here, on the issue linked above, or to me
directly.
What should I expect to happen next?
If the sense of the community is that this change is worthwhile, we will
send a breaking change announcement and land the new restrictions. If the
overall sense is that catching these issues is not worth the breakage in
existing code, we will abandon this proposal.
Please feel free to reach out to me with questions or feedback.
thanks,
-leaf
--
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
--
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+***@dartlang.org.
'Jakob Roland Andersen' via Dart Misc
2018-02-22 09:06:58 UTC
Permalink
I think you just need to add an explicit 'void' type:

void nowExplicitlyVoid() => returnsVoid();

should be fine. Without the type, it's implicitly dynamic, and you can't
(in the proposal) return void from a dynamic function.
Post by Istvan Soos
Is there a language or tooling benefit of making this an error instead
of a linter hint (that is optional)?
The `implicitDynamic() => returnsVoid();` format is usually a
one-liner, while putting braces around it pushes it to three lines,
without much visible benefits otherwise. The effect is more
unfavourable when we are passing in a function closure (e.g.
Iterable.forEach).
It would be sad to lose the compact code without much upside.
Cheers,
Istvan
On Thu, Feb 22, 2018 at 12:57 AM, 'Leaf Petersen' via Dart Misc
Post by 'Leaf Petersen' via Dart Misc
TLDR: We are soliciting feedback on the proposal to disallow return a
`void`
Post by 'Leaf Petersen' via Dart Misc
typed value from a function whose return type is not `void`.
The original Dart 2 proposal for the treatment of `void` attempted to
prevent `void` typed values from being accidentally used. See here for
details on the proposal: https://github.com/dart-lang/sdk/issues/30597 .
When we prototyped this proposal, we felt that some of the proposed
restrictions were too intrusive. We recently landed a subset of these
https://groups.google.com/forum/#!topic/flutter-dev/scnh7SfYa_o). We
are
Post by 'Leaf Petersen' via Dart Misc
proposing to add one additional restriction, based on our observation
that
Post by 'Leaf Petersen' via Dart Misc
fixing code broken by the change is relatively benign, and that it has
essentially no impact on flutter framework code.
What is the proposed change?
In Dart 1, it was legal to return a `void` typed value from a function
with
Post by 'Leaf Petersen' via Dart Misc
return type `dynamic`. This is occasionally done implicitly (where the
return type is left off the function) and only very infrequently done
explicitly.
```dart
void returnsVoid() {}
// Occasionally seen
implicitDynamic() => returnsVoid();
// Rare
dynamic explicitDynamic() => returnsVoid();
```
We are proposing to make both of these uses an error, and are soliciting
feedback from the community about the impact and desirability of these
changes.
What should I do?
If you are opposed to this change, either because you feel it's a bad
change, or because you feel that it will break too much of your existing
code, please provide feedback here, on the issue linked above, or to me
directly.
What should I expect to happen next?
If the sense of the community is that this change is worthwhile, we will
send a breaking change announcement and land the new restrictions. If
the
Post by 'Leaf Petersen' via Dart Misc
overall sense is that catching these issues is not worth the breakage in
existing code, we will abandon this proposal.
Please feel free to reach out to me with questions or feedback.
thanks,
-leaf
--
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
Post by 'Leaf Petersen' via Dart Misc
---
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
--
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
--
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+***@dartlang.org.
'Florian Loitsch' via Dart Misc
2018-02-22 10:31:59 UTC
Permalink
Most commonly when I don't write a type, it is because the function is
`void`. In that case writing a type is useless. No correct program would
ever behave differently with the `void` type.
As such, to me an implicit `dynamic` return type should thus allow
everything an explicit `void` allows.

Any advantage in disallowing it at the language level instead of as a
linter (where most people who care already require to write return types
everywhere...)?.

On Thu, Feb 22, 2018 at 10:07 AM 'Jakob Roland Andersen' via Dart Misc <
Post by 'Jakob Roland Andersen' via Dart Misc
void nowExplicitlyVoid() => returnsVoid();
should be fine. Without the type, it's implicitly dynamic, and you can't
(in the proposal) return void from a dynamic function.
Post by Istvan Soos
Is there a language or tooling benefit of making this an error instead
of a linter hint (that is optional)?
The `implicitDynamic() => returnsVoid();` format is usually a
one-liner, while putting braces around it pushes it to three lines,
without much visible benefits otherwise. The effect is more
unfavourable when we are passing in a function closure (e.g.
Iterable.forEach).
It would be sad to lose the compact code without much upside.
Cheers,
Istvan
On Thu, Feb 22, 2018 at 12:57 AM, 'Leaf Petersen' via Dart Misc
Post by 'Leaf Petersen' via Dart Misc
TLDR: We are soliciting feedback on the proposal to disallow return a
`void`
Post by 'Leaf Petersen' via Dart Misc
typed value from a function whose return type is not `void`.
The original Dart 2 proposal for the treatment of `void` attempted to
prevent `void` typed values from being accidentally used. See here for
details on the proposal: https://github.com/dart-lang/sdk/issues/30597
.
Post by 'Leaf Petersen' via Dart Misc
When we prototyped this proposal, we felt that some of the proposed
restrictions were too intrusive. We recently landed a subset of these
https://groups.google.com/forum/#!topic/flutter-dev/scnh7SfYa_o). We
are
Post by 'Leaf Petersen' via Dart Misc
proposing to add one additional restriction, based on our observation
that
Post by 'Leaf Petersen' via Dart Misc
fixing code broken by the change is relatively benign, and that it has
essentially no impact on flutter framework code.
What is the proposed change?
In Dart 1, it was legal to return a `void` typed value from a function
with
Post by 'Leaf Petersen' via Dart Misc
return type `dynamic`. This is occasionally done implicitly (where the
return type is left off the function) and only very infrequently done
explicitly.
```dart
void returnsVoid() {}
// Occasionally seen
implicitDynamic() => returnsVoid();
// Rare
dynamic explicitDynamic() => returnsVoid();
```
We are proposing to make both of these uses an error, and are soliciting
feedback from the community about the impact and desirability of these
changes.
What should I do?
If you are opposed to this change, either because you feel it's a bad
change, or because you feel that it will break too much of your existing
code, please provide feedback here, on the issue linked above, or to me
directly.
What should I expect to happen next?
If the sense of the community is that this change is worthwhile, we will
send a breaking change announcement and land the new restrictions. If
the
Post by 'Leaf Petersen' via Dart Misc
overall sense is that catching these issues is not worth the breakage in
existing code, we will abandon this proposal.
Please feel free to reach out to me with questions or feedback.
thanks,
-leaf
--
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
Post by 'Leaf Petersen' via Dart Misc
---
You received this message because you are subscribed to the Google
Groups
Post by 'Leaf Petersen' via Dart Misc
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send
an
--
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
--
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
--
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+***@dartlang.org.
tatumizer-v0.2
2018-02-22 13:34:34 UTC
Permalink
The idea to treat undeclared return type as 'dynamic' in function
signatures was OK for dart 1 But if the language was designed today
(without dart 1 legacy), I don't think this decision would be considered
sensible.
What if dart 2 starts treating omitted return type as void by default? Yes,
it will break some code, but compiler will flag all errors, and the fix, in
most cases, is trivial

From another perspective: how common is it to REALLY return something from
such functions?
My unscientific guess is that in majority of cases, omitted return type
really means 'void'. And if this is the case, the choice of 'default return
type' should follow 'most statistically likely' scenario, that's what
'default' is all about.
--
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+***@dartlang.org.
'Leaf Petersen' via Dart Misc
2018-02-23 01:16:45 UTC
Permalink
Post by Istvan Soos
Is there a language or tooling benefit of making this an error instead
of a linter hint (that is optional)?
Yes, this is a good question. I think it just comes down to whether this
is something that is considered broadly valuable enough that it should be
part of the language, or just a hint.
Post by Istvan Soos
The `implicitDynamic() => returnsVoid();` format is usually a
one-liner, while putting braces around it pushes it to three lines,
without much visible benefits otherwise. The effect is more
unfavourable when we are passing in a function closure (e.g.
Iterable.forEach).
Note that for closures, we will infer `void` as the return type. So
`.forEach((a) => returnsVoid())` should be fine.

It would be sad to lose the compact code without much upside.
Noted. Thanks for the feedback.

-leaf
Post by Istvan Soos
Cheers,
Istvan
On Thu, Feb 22, 2018 at 12:57 AM, 'Leaf Petersen' via Dart Misc
Post by 'Leaf Petersen' via Dart Misc
TLDR: We are soliciting feedback on the proposal to disallow return a
`void`
Post by 'Leaf Petersen' via Dart Misc
typed value from a function whose return type is not `void`.
The original Dart 2 proposal for the treatment of `void` attempted to
prevent `void` typed values from being accidentally used. See here for
details on the proposal: https://github.com/dart-lang/sdk/issues/30597 .
When we prototyped this proposal, we felt that some of the proposed
restrictions were too intrusive. We recently landed a subset of these
https://groups.google.com/forum/#!topic/flutter-dev/scnh7SfYa_o). We
are
Post by 'Leaf Petersen' via Dart Misc
proposing to add one additional restriction, based on our observation
that
Post by 'Leaf Petersen' via Dart Misc
fixing code broken by the change is relatively benign, and that it has
essentially no impact on flutter framework code.
What is the proposed change?
In Dart 1, it was legal to return a `void` typed value from a function
with
Post by 'Leaf Petersen' via Dart Misc
return type `dynamic`. This is occasionally done implicitly (where the
return type is left off the function) and only very infrequently done
explicitly.
```dart
void returnsVoid() {}
// Occasionally seen
implicitDynamic() => returnsVoid();
// Rare
dynamic explicitDynamic() => returnsVoid();
```
We are proposing to make both of these uses an error, and are soliciting
feedback from the community about the impact and desirability of these
changes.
What should I do?
If you are opposed to this change, either because you feel it's a bad
change, or because you feel that it will break too much of your existing
code, please provide feedback here, on the issue linked above, or to me
directly.
What should I expect to happen next?
If the sense of the community is that this change is worthwhile, we will
send a breaking change announcement and land the new restrictions. If
the
Post by 'Leaf Petersen' via Dart Misc
overall sense is that catching these issues is not worth the breakage in
existing code, we will abandon this proposal.
Please feel free to reach out to me with questions or feedback.
thanks,
-leaf
--
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
Post by 'Leaf Petersen' via Dart Misc
---
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
--
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
--
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+***@dartlang.org.
Patrice Chalin
2018-02-23 11:30:07 UTC
Permalink
Post by 'Leaf Petersen' via Dart Misc
Yes, this is a good question. I think it just comes down to whether this
is something that is considered broadly valuable enough that it should be
part of the language, or just a hint.
I share Istvan's concern: if there isn't strong evidence that this will
help flag real problems, w/o introducing a lot of false negatives, then I'd
vote leave such a check to the linter.

IMHO, it is better to avoid one-off rules and keep the core language
semantics as simple as possible because, as you know, that translates into
simpler tooling, and a language that is easier to understand by its users.

I believe that currently, dynamic is meant to be a placeholder for _any_
type, including void. In Dart 1, void is equivalent to the unit type Null,
since Dart 1 (like JS) has _every_ function return a value, even a void
function. Will this still hold true in Dart 2+? If not, then void could be
(re-)defined to be the empty type, and an explicit dynamic could mean "any
non-empty type".
--
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+***@dartlang.org.
'Erik Ernst' via Dart Misc
2018-02-23 12:33:18 UTC
Permalink
Post by Patrice Chalin
Post by 'Leaf Petersen' via Dart Misc
Yes, this is a good question. I think it just comes down to whether this
is something that is considered broadly valuable enough that it should be
part of the language, or just a hint.
I share Istvan's concern: if there isn't strong evidence that this will
help flag real problems, w/o introducing a lot of false negatives, then I'd
vote leave such a check to the linter.
IMHO, it is better to avoid one-off rules and keep the core language
semantics as simple as possible because, as you know, that translates into
simpler tooling, and a language that is easier to understand by its users.
The simple rule is "values of type `void` are discarded". One exception was
added, to cover situations where the given type annotations are misleading
(for historic reasons or whatever): an explicit cast.

The proposals where the desirably concise `foo(...) => voidFunc(...);`
functions get the return type `void` would enable us to keep this simple
model.

(I hope, but I do not know for sure, that this can be achieved without
introducing any significant complications to top-level inference: it would
only apply to "simple" situations, e.g., arrow functions where the body is
an invocation of a function whose return type is specified explicitly.)

In contrast, assuming that those concise functions have return type
`dynamic`, I think it adds extra complexity to the language if we allow
these void-typed values to be returned. It's also rather error-prone: we're
silently transforming "don't use this value" to "you can use this value in
_every_ way you want", based on a *missing* declaration.

I believe that currently, dynamic is meant to be a placeholder for _any_
Post by Patrice Chalin
type, including void. In Dart 1, void is equivalent to the unit type Null,
since Dart 1 (like JS) has _every_ function return a value, even a void
function. Will this still hold true in Dart 2+? If not, then void could be
(re-)defined to be the empty type, and an explicit dynamic could mean "any
non-empty type".
--
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
--
Erik Ernst - Google Danmark ApS
Skt Petri Passage 5, 2 sal, 1165 KÞbenhavn K, Denmark
CVR no. 28866984
--
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+***@dartlang.org.
Loading...