[Issue 21926] New: std.conv.octal(string) should allow leading zeros

[d-bugmail at puremagic.com]

https://issues.dlang.org/show_bug.cgi?id=21926

          Issue ID: 21926
           Summary: std.conv.octal(string) should allow leading zeros
           Product: D
           Version: D2
          Hardware: x86_64
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P1
         Component: phobos
          Assignee: nobody at puremagic.com
          Reporter: witold.baryluk+d at gmail.com

In C (and so often in my C header), octal literals can have leading zeros:

Example (from include/uapi/linux/stat.h)

```
#define S_IFMT  00170000
#define S_IFSOCK 0140000
#define S_IFLNK  0120000
#define S_IFREG  0100000
#define S_IFBLK  0060000
#define S_IFDIR  0040000
#define S_IFCHR  0020000
#define S_IFIFO  0010000
#define S_ISUID  0004000
#define S_ISGID  0002000
#define S_ISVTX  0001000
```

The D lexer / grammar, and std.conv.parse(string s, int radix = 8) does support
does support leading zeros.

But the std.conv.octal doesn't.

For example this is rejected:

enum S_ISVTX = octal!"0001000";

I believe the leading zeros for octal from a string (not from integer!), should
be allowed to easy the automated and/or manual conversions of definitions
from C, or older D code, and to help with column alignment (as in the example
above).

The current code in std.conv claims, that leading zeros can cause confusion
in octal strings, but that is not true (leading zeros were already supported
for octals, and meant octals. octal template name is very explicit, and can't
be confused with anything else. using them in octal string at compile time,
again requires actually writing it explicitly, so again there is no way for
confusion. plus leading zeros are ignored, but the resulting value is the same,
so again, there is no way for confusion.).

--