ES proposal: Boolean.parse

Boolean.parse.md

Boolean.parse(string)

Specification

Parses the string argument as a boolean. The boolean returned represents the value true if the string argument is not null and is equal, ignoring case, to the string "true".

When the Boolean.parse function is called with a string argument the following steps are taken:

1. If Type(string) is not "string"
   • Return false
2. Let normalizedString be the result of applying String.prototype.toLowerCase on the string
3. If normalizedString is "true"
   • Return true
4. Return false

Examples

Boolean.parse('true'); // true
Boolean.parse('false'); // false

// In contrast with problematic:
Boolean('false'); // true

Use-case

Storages which doesn't support actual boolean values at serialization, and only have string-based value types. Example: Node's env arguments.

so basically this is the equivalent of /^true$/i.test(str) ?
I'd also be horrified by a Boolean.parseBoolean(1) that returns false.

[nevermind]

Boolean.parseBoolean seems rather redundant as a name. Why isn't it just called Boolean.parse? The "Int" in Number.parseInt is a qualifier that is needed because what is recognized is only a subset of string encoded Numbers. But this operation deals with all the normal string values produced by toStringing a Boolean value. So the qualification is not really needed.

Normally, operations like this would do a ToString on the argument value and then process that rather than what you do in step 1.

It's weird that you return false for anything that isn't "true". For example, a typo like "trye" returnfalse. I think you should treat anything that isn't "true"/"false" (although you probably should trim leading/trailing blanks) as an throwing error.

So many issues with a so small proposal:

1. “If Type(string) is not String, return false” should be “Let string be ? ToString(string)” for consistency with Number.parseInt, Number.parseFloat, Date.parse, JSON.parse, and pretty much every method that expects a string.
2. Neither JavaScript nor JSON recognises True, TRUE, etc, as a valid variant of true. There is no clear reason to innovate in that regard. Otherwise, one should consider recognising yes.
3. Another inconsistency: All of Number.parseInt, Number.parseFloat, Date.parse, and JSON.parse ignore leading and trailing spaces, contrarily to the proposed Boolean.parseBoolean.
4. One can certainly find more useful than false for Boolean.parseBoolean("foo"). For example Number.parseInt, Number.parseFloat and Date.parse return NaN for unrecognised string, and JSON.parse throws an error.

Thanks guys, all are valid points. In the original es-discuss thread, I made truthy/falsey values. Initially Boolean.parseBoolean(1) would result true, and Boolean.parseBoolean(0) would result false. But then reduced it to Java's appropriate Boolean.parseBoolean method.

EDIT: update to Boolean.parse.

Examples are still using parseBoolean instead of parse

@lahmatiy, thanks, fixed!