Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
proposal: Go 2: language: make slices of constant strings constant if the indexes are constant #28591
This will probably be assigned a Go2 label, although I think that it could be done during Go 1.
Consider multiline string constants:
const multiline = ` This is a long text that spans multiple lines and then ends. `
If you feed this text to a parser and it finds a problem on the first line ("This is a long text"), it will actually report that the error is on the second line because of the leading newline. One might think that this is easily solved by slicing the string:
const multiline = ` This is a long text that spans multiple lines and then ends. `[1:]
But this won't compile. The Spec currently says:
Why not make it constant? After all,
There are other solutions to this. One could just use
It turns out that this proposed change is not backward-compatible after all ...
var _ = -"A"
we will get an error: -"A" (constant -65 of type byte) overflows byte . This is currently (without the change) valid code. Oops!
For similar reasons, constant index expressions are not backwards-compatible either. The length of a constant slice expression
var _ uint = -uint(len("abc"[0:2]))
(Without the change, these values are not constant, and the compiler won't complain.)
@griesemer FWIW, my most immediate reaction would be to suggest postponing this from Go 1.15 if that is indeed that case (for most of the reasons discussed in the related golang-dev thread, including your comment here). This change does not seem worth triggering the first use of the
edit: sorry, mangled link.
To the contrary! A minor, mostly-backward-compatible change seems like a great way to try out the mechanism without causing too much churn if it doesn't go as well as we expect.
We discussed this issue in the proposal review committee. Since this proposal is not backward-compatible and we put a premium on language stability, we decided to not proceed with this for Go 1.15.
We discussed introducing a vet check instead, but it doesn't seem warranted since this change is essentially language fine-tuning - a "nice to have" if it were backward-compatible, but not important.
I will leave this open for future consideration, when non-backward compatible changes become viable due to universal use of modules.