codeconsole commented on PR #16322: URL: https://github.com/apache/grails-core/pull/16322#issuecomment-5702749343
Agreed, and fixed in `762cffe848`. I reproduced your table on the Groovy 5.1.2 jar first: under the exact-binary rule every `BigDecimal`↔`Double`/`Float` row except the dyadic ones is rejected, and under the round-trip rule all of them convert while every rejection you listed stays rejected. **Guard:** `sameNumericValue` keeps the `Double.compare` branch for the floating-point family and compares everything else through the decimal strings again. `exactDecimalValue` is gone. The one visible change is the one you named: `10^23` as a `BigInteger` becomes a `Double` and renders `1.0E23`. **Spec:** the `'Double' | 0.1G` and `'BigDecimal' | 0.1d` rows moved to the conversion table with `0.1` expected, alongside `19.99G`→`double`/`Float`, `19.99d`/`0.1f`/`0.30000000000000004d`→`BigDecimal`, and the `BigInteger`→`Double` case. The rejection table gains `42.5d`→`Integer`, `123456789012345678L`→`Double` and `1.0E+23G`→`Long`. **Nit:** the `1E400` and `-Infinity` rows sit next to the `Date` case now, and the two features discriminate on what produced the failure: the guard's message ends "without changing it" with no cause, Groovy's refusals say "cannot be converted" with the cause named per row (`GroovyCastException` for the `Date`, `GroovyRuntimeException` for the other two; on 5.1.2 the former is not a subtype of the latter, which is why the rows are separate). **Doc:** line 58 rewritten to your wording. Verified: `GspCompileStaticSpec` 75 tests, 0 failures with `--no-build-cache`; with the exact-binary rule put back, exactly the eight cross-family conversion rows fail and nothing else; `:grails-gsp-core:codeStyle` clean. -- 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]
