anchor.diff:  
   ==== `toBoolean()`
   
  -The new `toBoolean()` function would only accept the two strings `'true'` and `'false'` as valid inputs, and would return `null` on any other input, similarly to how `toFloat()` and `toInt()` behave at the time of writing.
  +The new `toBoolean()` function would only accept the two strings `'true'` and `'false'`, with any case variants, as valid inputs, and would return `null` on any other input, similarly to how `toFloat()` and `toInt()` behave at the time of writing.
   
   === Examples
   
  
positive.code: .Convert strings to booleans.
  [source, cypher]
  ----
  UNWIND ['true', 'false', 'foo'] AS s
  RETURN toBoolean(s) // yields two booleans and one null
  ----
  
  === Interaction with existing features
  
negative.code: Following Cypher's guiding principles, explicit is better than implicit, and this CIP argues that `toInteger()` is a more explicit and better name.
  
  Furthermore, there is an opportunity to create a very simple and consistent rule that all scalar types should come with a type conversion function on the pattern `toX()` where `X` is the name of the type.
  Refer to the https://github.com/opencypher/openCypher/blob/master/cip/CIP2015-09-16-public-type-system-type-annotation.adoc#213-scalar-types[type system CIP] to learn more about Cypher scalar types.
  This has the consequence of adding a `toBoolean()` function to the language, creating a full set of conversion functions.
  
  == Proposal
  