I would make it parse any number literal allowed in the lexical grammar, and give the corresponding value.
On the other hand, I'm not convinced that it's really preferable to allow too much in a parse method. You should be wary of use-cases where you need to parse something, but don't actually know the format.

Removed Type-Defect label.
Added Type-Enhancement label.

Basically I want:
foo(num x) {
  identical(num.parse(x.toString()));
}

Semantically I propose:

num.parse(x, errorHandler) {
  bool isInt = true;
  num result = int.parse(x, onError(() { isInt = false; return 0; }));
  if (isInt) return result;
  bool isDouble = true;
  result = double.parse(x, () { isDouble = false; return 0.0; }));
  if (isDouble) return result;
  return errHandler(x);
}

Added Accepted label.

This comment was originally written by @butlermatt

I'd like to see this as well. Florian's comment #­2 is what I would expect as well. Since the 'best practice' seems to be to be to prefer 'num' unless you explicitly require an int/double, I would expect that a num.parse() exist.

With this missing it actually seems to enforce that you should use the explicit subtypes rather than num itself.

Added Ready-to-implement label.

Set owner to @lrhn.
Added Started label.

Issue #1981 has been merged into this issue.

Added Fixed label.