paulk-asert opened a new pull request, #2878: URL: https://github.com/apache/groovy/pull/2878
…me's number categories The runtime divides with floating-point math when either operand is a Float or Double, wrapper or primitive, and with BigDecimal math for integral, BigInteger and BigDecimal operands. The type checker only recognised primitive float and double, so Double / Integer was inferred as BigDecimal, and an operand typed as Number, whose runtime category is unknown, was inferred as BigDecimal too. Statically compiled code then cast the Double the runtime produced and failed. Unwrap before testing the floating category, and infer BigDecimal only when both operands belong to a category that divides that way; a Number operand yields Number. The group operations had the same blind spot from the other side: they took the category of whichever operand they recognised, so Number * int was int. An operand of unknown category now yields Number unless a floating-point partner decides the result, as it does at runtime. An arithmetic result that could not be typed before may now be a Number where it was an int or BigDecimal, so code that assigned it to a narrower type needs an explicit conversion, as the GROOVY-5539 test now shows. StringUtil.bar with Double arguments works without change. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
