spec: allow implementations to restrict constants to 16-bit binary exponents #13572
Comments
|
I support this proposal, for the rationale given. In Go 1.4 the compiler rejected exponents larger than 10000 (due to knowing the code didn't work for larger exponents) without any complaint from users. In earlier versions of Go, large exponents were silently mishandled, again without any complaint from users. |
|
As I said in the CL: While I sympathize with the sentiment and am sure to be overruled, I don't like this change because of the precedent it sets. This change is triggered by an inconvenience created by a new implementation of constants in the compiler, and rather than grapple with the requirements of the specification, the proposed remedy is to change the language. There's really no other way to spin this: we propose to change the language to simplify the implementation of the compiler. That may be a valid thing to do but it gives me a bad taste. |
|
@robpike go/compile does support the full 32-bit range because big.Float supports a 32bit range. The main issue is input and output. Decimal output works fine since it's only needed in error messages where a rounded 6-digit result is plenty. Decimal input is also working fine. Import and export use a binary format (new form) or a textual form with binary exponent; in all these cases exponent range is irrelevant. The current go/types implementation cannot handle it, but a pending and LGTM-ed CL ( https://go-review.googlesource.com/#/c/17360/ ) fixes that as well. I believe gccgo uses a C library for constant arithmetic which takes care of it. Thus, we have implementations now that are fully compliant. That said, the amount of effort (*) to get here seems incommensurable with the benefit: There's likely not a single use case (but for tests) where it matters (but I am happy to hear to the contrary from the community). (*) If only 16bit exponent implementations are required, a simple implementation might get away without the need for a (complex) floating-point library. Since such large constants are rare, representing them in full in memory is easily feasible on todays machines. |
|
PS: Should we decide to change to 16bit exponent range, for instance because no existing program (but for tests) ever needed a larger range, we don't close the door on expanding to 32bits again down the road in a fully backward-compatible way, should we have grossly underestimated the necessary floating-point constant range. |
|
With appropriate justification, as presented above, being present in the CL and release notes, I think this would be OK. |
|
LGTM |
|
CL https://golang.org/cl/17711 mentions this issue. |
@griesemer proposes changing the spec to allow implementations to restrict constants to those representable with signed 16-bit binary exponents. The current spec requires implementations to handle at least signed 32-bit binary exponents, so this is strictly speaking a language change. However, existing compilers have handled the very large values being excluded badly, if at all. It has been a constant (ha!) source of bugs and has basically never worked correctly, and we know of no compelling uses for numbers that big in a Go program. Given the difficulty of implementation and lack of utility, the proposal is to remove them. Since they have basically never worked correctly, removing them should affect no real programs.
The exact text is in https://go-review.googlesource.com/17711 but discussion should be on this issue.
The text was updated successfully, but these errors were encountered: