Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

spec: don't say that 0123i == 123i is for backward-compatibility #36386

Open
perillo opened this issue Jan 4, 2020 · 5 comments
Open

spec: don't say that 0123i == 123i is for backward-compatibility #36386

perillo opened this issue Jan 4, 2020 · 5 comments
Labels
NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Milestone

Comments

@perillo
Copy link
Contributor

perillo commented Jan 4, 2020

The Go Language Specification in https://golang.org/ref/spec#Imaginary_literals has the example

0123i         // == 123i for backward-compatibility

With the new number literal proposal implemented in Go 1.13, I think the comment should be changed, since now it is 0123 == 0o123 that should be considered to be for backward-compatibility.

Probably the examples in https://golang.org/ref/spec#Integer_literals

0600
0_600

should have a comment // == 0o600 for backward-compatibility.

@perillo
Copy link
Contributor Author

perillo commented Jan 4, 2020

Assuming that, theoretically, leading zeros in decimal integer literals should not permitted (as it is done in Python 3), then the comment in the first example should remain, and the same comment should be added in the second example.

@ianlancetaylor
Copy link
Member

I think the spec is correct. 0123i == 123i. That isn't obvious, because 0123 != 123. It's that way because of backward compatibility concerns.

On the other hand, 0o123i != 123i. That is as people expect.

@ianlancetaylor ianlancetaylor added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Jan 4, 2020
@perillo
Copy link
Contributor Author

perillo commented Jan 4, 2020

The problem is that with the addition of the 0o prefix (and forgetting the C legacy for octal literals syntax), an alternate reasoning is that 0123i was supposed to produce a compiler error, but instead means 123.

But I admit that my text was confusing, sorry.

What I would like to propose is to deprecate the old syntax for octal literals. The specification should mention, in the examples, the old syntax only for reference but it should suggest the use of the new 0o prefix (or discourage the old 0 prefix in new code).

@ianlancetaylor
Copy link
Member

CC @griesemer

I believe that it is already possible to use gofmt to rewrite old-style octal literals to new-style. I don't see a need to do anything else yet. Perhaps a few releases down the road we can deprecate the old-style octal literals, but not yet.

@perillo
Copy link
Contributor Author

perillo commented Jan 5, 2020

I think gofmt should not rewrite old-style octal literals to new-style, due to compatibility reason. Maybe it should be done by go fix?

IMHO, old-style octal literals should be rewritten to new-style in the standard library; and it should be done now, since there are no compatibility issue. Should I open a different issue?.

I agree that the deprecation should be done in future.
This issue title should be changed to deprecate old-style octal literals. It isn't only go_spec that should be updated, but also all the files in doc, and probably the go tour, too.

But, still, I'm not sure. Should all the official documents (excluding the spec) assume that the old-style octal literals never existed?

Thanks.

@dmitshur dmitshur changed the title doc/go_spec: don't say that 0123i == 123i is for backward-compatibility spec: don't say that 0123i == 123i is for backward-compatibility Feb 15, 2020
@ALTree ALTree added NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. and removed WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. labels Jun 18, 2021
@seankhliao seankhliao added this to the Unplanned milestone Aug 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Projects
None yet
Development

No branches or pull requests

4 participants