Method to parse bools

[DartBot]

This issue was originally filed by @seaneagan

---

The bool interface should provide a method to parse bool Strings:

interface bool {
  bool parse(String s, [bool ifInvalid]);
  //...
}

where parse's implementation is something like:

(String s, [bool ifInvalid]) {
  if(s === null || !(s == 'true' || s == 'false')) return ifInvalid;
  return s == 'true';
}

[DartBot]

This comment was originally written by @seaneagan

---

should be static:

static bool parse(String s, [bool ifInvalid]);

[anders-sandholm]

Not sure this is a library issue.
Florian, please re-assign to Area-Language, if appropriate.

---

cc @floitschG.
Added Area-Library, Triaged labels.

[floitschG]

Library is the right area.
Personally I would rather lean towards a bool.fromString constructor, but that would be inconsistent with Math.parseInt and Math.parseDouble. So this bug is probably dependent on what we decide to do with these functions.

[DartBot]

This comment was originally written by @seaneagan

---

issue #2868 is the dual of this issue for int, num, and double. I agree they should be consistent, and I would be ok with either constructors or static methods. I also like them as constructors, except for the fact that you would virtually always need to wrap calls to them in try blocks:

bool x;
try {
  x = new bool.parse(boolString);
} catch(BadBooleanFormatException) {
  x = false;
}

whereas a static method could just return null, simplifying it to:

bool x = bool.parse(boolString);
if(x == null) x = false;

or in the case where you want to throw an exception on an invalid bool String:

final bool x = bool.parse(boolString);
if(x == null) throw ...;

I slightly prefer "parse" over "fromString" since it's no less clear and yet shorter, but I wouldn't bikeshed it.

There's also the question of whether the comparison should be case-insensitive (e.g. allowing "True", "faLSE"), to which I believe the answer is no, since those do not (necessarily) represent bools in Dart code.

[DartBot]

This comment was originally written by ladicek@gmail.com

---

Remember that the constructor could (and probably should) actually be a factory constructor, which can also return null. I'm also a fan of calling it "parse".

[DartBot]

This comment was originally written by @seaneagan

---

I think it would be strange if "new bool.parse()" ever returned null. If "new " weren't required on constructor calls, then I would probably feel differently.

Also, whatever solution is used here should be consistently applied to Date.fromString (parse vs. fromString and static method vs. constructor).

[lrhn]

It's unclear which values should be allowed as input. Is 'true', 'True', and 'TRUE' all valid? Is 'TrUe'?

I'd prefer not forcing a string representation of booleans by having an official parse function.

---

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

[lrhn]

Since the function can be as simple as (x)=>x=="true" I'd prefer not to add it to the platform libraries. The textual representation of a boolean should generally be picked to match the context (maybe "yes"/"no" rather than "true"/"false"), and a general parsing function would only encourage using the generic name over a more suitable one.

---

Added NotPlanned label.