Make dart:core strong-mode clean.

sdk/lib/core/num.dart

Index: sdk/lib/core/num.dart
diff --git a/sdk/lib/core/num.dart b/sdk/lib/core/num.dart
index 38587b107abf2b08582079c866f1e8df940f1d2d..21f23eef18321ab7fc4b59aa397cdbb7ead0b0d6 100644
--- a/sdk/lib/core/num.dart
+++ b/sdk/lib/core/num.dart
@@ -439,14 +439,15 @@ abstract class num implements Comparable<num> {
   static num parse(String input, [num onError(String input)]) {
     String source = input.trim();
     // TODO(lrn): Optimize to detect format and result type in one check.
-    num result = int.parse(source, onError: _returnNull);
+    num result = int.parse(source, onError: _returnIntNull);
     if (result != null) return result;
-    result = double.parse(source, _returnNull);
+    result = double.parse(source, _returnDoubleNull);
     if (result != null) return result;
     if (onError == null) throw new FormatException(input);
     return onError(input);
   }
 
-  /** Helper function for [parse]. */
-  static _returnNull(_) => null;
+  /** Helper functions for [parse]. */
+  static int _returnIntNull(String _) => null;

[Leaf, 2016/04/19 23:58:36]

The String annotation should not be required.  As an aside, this is one of those
cases where being able to "partially apply" a generic function would be useful. 
I think we actually would currently instantiate this for you if you just made
your original _returnNull a generic returning T.

I presume that the inline closure is avoided because new closures will have to
be allocated every time in order to satisfy the Dart identity semantics?

[floitsch, 2016/04/20 14:15:05]

But that's what the input should be. So I prefer keeping them.
I think this is a good case where you wouldn't want that to happen, since you
would have to reallocate a new tear-off every time you want to use the function.
Even worse, I would expect the generated code to be much less efficient.
correct. (something I would like to make unspecified)

[Leaf, 2016/04/20 17:48:37]

ok.
I'd hope it would be inlined, but it isn't a slam dunk.  We should make sure
that the semantics admits inlining these, if we allow them.
+1

+  static double _returnDoubleNull(String _) => null;
 }