Skip to content

Instantly share code, notes, and snippets.

What would you like to do?
ES proposal: Boolean.parse



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


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

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


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


This comment has been minimized.

Copy link

WebReflection commented Mar 20, 2017

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


This comment has been minimized.

Copy link

RReverser commented Mar 20, 2017



This comment has been minimized.

Copy link

allenwb commented Mar 20, 2017

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.


This comment has been minimized.

Copy link

claudepache commented Mar 20, 2017

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.

This comment has been minimized.

Copy link
Owner Author

DmitrySoshnikov commented Mar 20, 2017

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.


This comment has been minimized.

Copy link

lahmatiy commented Mar 21, 2017

Examples are still using parseBoolean instead of parse


This comment has been minimized.

Copy link
Owner Author

DmitrySoshnikov commented Mar 21, 2017

@lahmatiy, thanks, fixed!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.