The pre-1.18 compiler treats untyped constants of rune kind (such as 'a', '1' << 10, etc.) passed as arguments to the built-in functions print and println differently than other constants if those values overflow the 'rune' range.
Example, compiled using pre-1.18 compiler:
var_='1'<<32// constant 210453397504 overflows runeprintln('1'<<32) // no error
Example, compiled using 1.18 compiler:
var_='1'<<32// cannot use '1' << 32 (untyped rune constant 210453397504) as rune value in variable declaration (overflows)println('1'<<32) // cannot use '1' << 32 (untyped rune constant 210453397504) as rune value in argument to println (overflows)
The pre-1.18 compiler accepts an int64 value if an int32 value is not sufficient, rather than reporting an error as would be warranted by the usual assignment and parameter passing rules.
The compiler should consistently apply parameter passing rules from now on, even for arguments to the "magic" built-in functions print and println.
For existing code that doesn't compile anymore there are a couple of work-arounds:
Use a conversion (e.g., int64('1' << 32)).
Compile using the 1.17 compiler by setting the -G=0 compiler flag. This doesn't require code changes.
Current implementations provide several built-in functions useful during bootstrapping. These functions are documented for completeness but are not guaranteed to stay in the language.
Thus, arguably a (non-temporary) correct program should not be relying on these functions in the first place. At the very least we should be in the position to make this minor adjustments.
If the proposal is accepted, nothing needs to be done; this is already the new behavior of the compiler.
If the proposal is not accepted, the compiler needs to be adjusted such that untyped rune constant arguments to print and println are treated as int64 values if they overflow as rune (i.e., int32) values.
The text was updated successfully, but these errors were encountered: