Currently, when summing longs in an accumulate, we get something like this:

when ...
      $t : Number(...) from accumulate(...,
            sum($p.getLongWeight()))
then scoreHolder.addHard($t.longValue());

This has 3 problems:

• Loss of precision: the long sum `1881617265586265321L` will incorrectly return `1.88161726558626534E18`, so `13` too much! The BigDecimal sum of `0.09` and `0.01` will also be incorrect.
• Loss of performance: Summing with a Double total is significantly slower than summing with a Long total or an Integer total.
• Example complexity (minor, not all of us agree on this argument): the use of `Number` is an abstraction that doesn't bring any value to the use case. It's worthless complexity.

Solution proposal A) for 7.0 as discussed with Mario:
Based on the argument type to the sum function, the compiler selects a different sum function implementation. This is similar to java overloading mechanism, where `System.out.println(1)` selects a different method implementation than `System.out.println(2.0)`.

Support sum(Long):

when ...
      $t : Long(...) from accumulate(...,
            sum($p.getLongWeight()))
then scoreHolder.addHard($t);

and sum(BigDecimal):

when ...
      $t : BigDecimal(...) from accumulate(...,
            sum($p.getBigDecimalWeight()))
then scoreHolder.addHard($t);

and also support sum(Integer) and sum(BigInteger).
If this works well, we can consider it for other functions as well in a different jira issue.

Special case 1: sum(Number) should default to sum(Double) for backwards compatibility.

when ...
      $t : Number(...) from accumulate(...,
            sum($p.getNumberWeight()))
then scoreHolder.addHard($t.doubleValue());

Not-so-special case 2: to sum integers into a long total, the user should just use:

      $t : Long(...) from accumulate(...,
            sum((long) $p.getIntWeight()))