anchor.diff:  RETURN size(coll)
   ----
   
  -Calculate the cosine of a value:
  +.Calculate the cosine of a value:
   [source, cypher]
   ----
   WITH 1 AS int
   RETURN cos(int) // coerced to a float
   ----
   
  -Store a list of numbers as a node property:
  +.Store a list of numbers as a node property:
   [source, cypher]
   ----
   WITH [1, 1.0] AS list
   CREATE ({l: list})) // coerced to a list of floats
  +----
  +
  +.Extract a specific element from a list by index:
  +[source, cypher]
  +----
  +WITH ['a', 'b', 'c'] AS list, 1.5 AS float
  +RETURN list[toInteger(float)] // explicit conversion required
   ----
   
   === Syntax
  
positive.code: 
  There are no new semantics to consider.
  
  === Alternatives
  
  There are plenty of additional coercions to consider.
  Coercion from `NUMBER` to `FLOAT` would, under the current type system, function exactly the same as the existing `INTEGER` to `FLOAT` coercion, and it would solve the issue discussed in <<Background>>.
  
  [source, cypher]
  ----
  WITH [1, 1.01] AS numbers
  RETURN [ x IN numbers | cos(x) ]
  ----
  
  Pros:
  
  * The coercion could be useful as a pragmatic approach to predict the user intention (e.g. writing 1 when meaning 1.0) rather than strictly enforcing the type.
  
  Cons:
  
  * The coercion could lose precision (e.g. integer to float, but we already have this behavior currently).
  * The addition of a new number type (e.g. complex numbers) could make the coercion nonsensical.
  
  Due to the current precision loss, an alternative could also be to have more restrictions for type coercion, and disallow the current integer-to-float coercion.
  
  == What others do
  
  PostgreSQL link:http://www.postgresql.org/docs/9.0/static/typeconv-overview.html[states three principles] that guide their handling of type conversions:
  
  * Implicit conversions should never have surprising or unpredictable outcomes.
  * There should be no extra overhead in the parser or executor if a query does not need implicit type conversion.
    That is, if a query is well-formed and the types already match, then the query should execute without spending extra time in the parser and without introducing unnecessary implicit conversion calls in the query.
  * Additionally, if a query usually requires an implicit conversion for a function, and if then the user defines a new function with the correct argument types, the parser should use this new function and no longer do implicit conversion to use the old function.
  
  link:https://msdn.microsoft.com/en-us/library/ms191530.aspx[SQL Server] and link:http://docs.oracle.com/cd/B19306_01/server.102/b14200/sql_elements002.htm#i163326[Oracle DB] has larger type sets and defines many implicit conversion between the types.
  
negative.code: RETURN coll[0]
  ----
  
  .Return the size of a non-empty list:
  [source, cypher]
  ----
  WITH [1, 2, 3.5] AS coll
  