Comment 1:

Status changed to LongTerm.

Comment 2 by autophile:

This is hardly a problem unique to Go. You'd get the same issue in C, C++, or Java.
Although I agree that binary 
literals would be very convenient to help with bit twiddling.

Comment 3 by JQBalter:

For a new language that is trying to avoid some of the problems of languages like C,
C++, and Java, pointing out that those languages have some problem is hardly a reason
not to eliminate the problem.

Comment 4 by yukuku:

I agree with disallowing 0... syntax for octal. I couldn't think a reason we need
octal numbers beside for chmod(file, 0755).

Comment 5 by dschauer:

@OP, I agree, even though decimal is the default, since we already have 0x, we need
0b, 0o, and 0d, since those are the most common bases used in computer programming.
Go is a fresh start, it would be best to avoid all the previous confusion and
problems caused by leading 0s being octal. I see no problem with having to use 0o0644
for a file permission even if it looks kind of funny.

Comment 6:

We have talked this over a lot and decided that, although it might have been better to
leave octal out 
from the beginning, taking it out has major consequences and compensating for its
removal will make 
the language uglier. First, if octal goes away then we would want to forbid leading
zeros in decimal 
numbers because people porting  or interfacing to C code, or even people used to writing
C code, would 
have uncaught subtle errors.  That alone makes the opening argument in the discussion
less convincing: 
remove octal so we can have leading zeros, but then we can't have leading zeros because
of the bugs 
that come in.  One could argue that the bugs are limited in scope, but they will happen
and be hard to 
find.
And if we're going to play with radix changes for inputting numbers, we would want to
fix the problem 
once and for all, with something like 16r8000 and 8r377, but those don't sit right;
they're just ugly.  Of 
course one could grandfather 0x but then there are two unrelated notations for numbers,
and that's bad.
Finally, can we remove octal from character and string constants?  If not, there's an
inconsistency that's 
troubling.  The relationship between char constants, string constants, and integer
constants is a careful 
balance and this gets us in unsettling territory.
So after a long discussion, we've decided to leave the status quo, which is familiar to
everyone, because 
the fix seems to make things more uglier and more complicated rather than simpler.

Status changed to WontFix.

Comment 7 by FlyMyPG:

Sure, keep the legacy octal syntax.  But that's not a reason NOT to also add a more 
explicit syntax.
Add a compiler flag to warn about the risky/legacy numeric literals (including stuff 
like "0O", if possible in the new syntax), and add a flag to gofmt to permit auto-
conversion to the most explicit syntax.
Then wait a year, grep the Go application base, and check the ratio of legacy octals 
to "new" octals.  If "new" octals dominate heavily, only then would it be useful to 
consider deleting the legacy octal syntax from Go.

Comment 8 by gherald:

Agreed with the above.  Even if you persist with a blanket 'design decision'
precluding warnings for legacy octal, a new systems language ought to have an
explicit alternative like 0o--and more usefully, 0b for binary and optional _ separators.

I am just starting to work in Go and this is the first thing I have come across that appears as an actual bug in the language and I can't believe it had been reviewed and accepted "Won't Fix" just because others had jumped off that bridge before.

Talk about uncaught subtle errors ... 045 is a completely legitimate decimal number (and is even often written that way as a decimal in many forums, such as when talking about a course or heading among others). Interpreting a legitimate decimal constant as octal just because of a leading 0 is mathematically wrong and misleading, even if other languages have done that before.

@jasonpfox There is no point to having a discussion on a closed issue. See https://golang.org/wiki/Questions .

So how do we get the issue reopened?

Jason Fox

jpfox@alumni.rice.edu

On Wed, Jun 15, 2016 at 2:23 PM, Ian Lance Taylor notifications@github.com
wrote:

@jasonpfox https://github.com/jasonpfox There is no point to having a
discussion on a closed issue. See https://golang.org/wiki/Questions .

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#151 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AQY2pk_mDGwW-351-5MST6WlrDdeIuhxks5qMEMtgaJpZM4I2oXm
.

@jasonpfox Take it to a forum, as described in the link above.

But the issue will not get reopened, because changing anything in this area would break the Go 1 guarantee (https://golang.org/doc/go1compat.html).

See also the discussion in: #12711