[
https://issues.apache.org/jira/browse/GROOVY-12471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18130549#comment-18130549
]
Jochen Theodorou commented on GROOVY-12471:
-------------------------------------------
I think in this case the solution would not be to let Number.abs() simulate
dynamic dispatch. Instead I think we should let the static compiler skip this
method. And then the question is why does dynamic Groovy need it? It does not.
Therefore, I would suggest deprecating it.
> SC: Method abs misbehaves under static compilaton
> -------------------------------------------------
>
> Key: GROOVY-12471
> URL: https://issues.apache.org/jira/browse/GROOVY-12471
> Project: Groovy
> Issue Type: Bug
> Affects Versions: 2.5.23, 3.0.25, 5.0.3, 4.0.33, 5.1.3, 6.0.0
> Reporter: Björn Kautler
> Priority: Major
>
> The snippet
> {code:groovy}
> @groovy.transform.CompileStatic
> def delta(Number item, Number value) {
> (item - value).abs()
> }
> println delta(2.2, 3.3)
> println delta(Long.MAX_VALUE, 1)
> {code}
> produces the outputs "1" and "2" while it should be "1.1" and
> "9223372036854775806".
> I assume the problem is, that SC chooses {{DGM.abs(Number)}} which unluckily
> assumes that {{{}Long{}}}, {{{}Float{}}}, {{{}Double{}}}, {{{}BigInteger{}}},
> and {{BigDecimal}} are handled by other methods (DGM or in the type itself)
> and thus treats any input as integer or smaller and returning {{{}int{}}},
> while this assumption does not necessarily hold under static compilation.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
