SDK fixes

tool/input_sdk/lib/internal/list.dart

Index: tool/input_sdk/lib/internal/list.dart
diff --git a/tool/input_sdk/lib/internal/list.dart b/tool/input_sdk/lib/internal/list.dart
index 6b94c6cbbf9197b3a135d78eedbbe90ae15fa1c0..3e87762c317d2dfd1f93a16e81e2868126809f24 100644
--- a/tool/input_sdk/lib/internal/list.dart
+++ b/tool/input_sdk/lib/internal/list.dart
@@ -248,7 +248,7 @@ class ListMapView<E> implements Map<int, E> {
 
   ListMapView(this._values);
 
-  E operator[] (int key) => containsKey(key) ? _values[key] : null;
+  E operator[] (Object key) => containsKey(key) ? _values[key] : null;

[vsm, 2015/05/04 21:09:21]

This is consistent with the Map.[] - but perhaps the cleaner solution is to
change that to take the Key type?  I guess this choice (Object vs the key or val
type) appears a few places though.

[Leaf, 2015/05/04 21:50:42]

Yes, I'd probably prefer that as well.  I was trying to minimize breaking API
changes though, with an eye towards potentially upstreaming some of these
changes.

A related one that came up as well was with inconsistent types for Set
intersection and difference (Set<K> vs Set<Object>).

   int get length => _values.length;
 
   Iterable<E> get values => new SubListIterable<E>(_values, 0, null);
@@ -257,7 +257,7 @@ class ListMapView<E> implements Map<int, E> {
   bool get isEmpty => _values.isEmpty;
   bool get isNotEmpty => _values.isNotEmpty;
   bool containsValue(Object value) => _values.contains(value);
-  bool containsKey(int key) => key is int && key >= 0 && key < length;
+  bool containsKey(Object key) => key is int && key >= 0 && key < length;
 
   void forEach(void f(int key, E value)) {
     int length = _values.length;
@@ -280,7 +280,7 @@ class ListMapView<E> implements Map<int, E> {
   }
 
   /** This operation is not supported by an unmodifiable map. */
-  E remove(int key) {
+  E remove(Object key) {
     throw new UnsupportedError("Cannot modify an unmodifiable map");
   }