http://d.puremagic.com/issues/show_bug.cgi?id=2656

           Summary: Require 0o format for octal literals
           Product: D
           Version: unspecified
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: clugdbug@yahoo.com.au


D should follow Python's lead in removing the archaic, subtle, and unintuitive format for octal literals. The obvious choices are of the form 0c45 and 0o45. The key argument used for the "0o" format is here:

http://mail.python.org/pipermail/python-dev/2006-February/060351.html

and basically argues that since in printf(), "%o" is used for octal, whereas "c" is used for char, "o" is the natural choice.

Buggy code like

  a = 045;

is a very rare bug, but horribly difficult to identify.
Not a high priority, but it's the kind of C baggage which D has always aimed to
jettison.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2656





------- Comment #1 from jarrett.billingsley@gmail.com  2009-02-13 10:45 -------
Or, you know, it could just remove octal literals, period.  Since _no one uses 18-bit machines anymore_.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2656





------- Comment #2 from clugdbug@yahoo.com.au  2009-02-18 10:30 -------
(In reply to comment #1)
> Or, you know, it could just remove octal literals, period.  Since _no one uses 18-bit machines anymore_.

Yes. It's easy enough to make a CTFE function for the 03 users who actually
want octal literals.
The important thing is that:

static assert(010 != 07 + 1, "Octal is obsolete");

should not compile without error.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2656


Don <clugdbug@yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs@eml.cc


--- Comment #3 from Don <clugdbug@yahoo.com.au> 2010-03-12 08:25:16 PST ---
*** Issue 3837 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=2656



--- Comment #4 from bearophile_hugs@eml.cc 2010-03-12 09:10:38 PST ---
Thank you Don for spotting the bug duplication.
In bug 3837 I have shown a possible improvement for floating point numbers too:

Optionally D can also turn FP literals like the following into syntax errors:
.5
3.

To require something like:
0.5
3.0

(But this is less important than a safer octal syntax.)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=2656


Andrei Alexandrescu <andrei@metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrei@metalanguage.com


--- Comment #5 from Andrei Alexandrescu <andrei@metalanguage.com> 2010-03-12 09:26:28 PST ---
I have a simple suggestion - how about putting this in object.d:

template octal(string s)
{
    static assert(s.length > 0);
    static assert(s[0] >= '0' && s[0] < '8',
        "Incorrect character in octal constant: `" ~ s[0] ~ "'");
    if (s.length == 1)
    {
        enum ulong octal = s[0] - '0';
    }
    else
    {
        enum ulong octal = (s[0] - '0') + 8 * octal!(s[1 .. $]);
    }
}

unittest
{
    static assert(octal!"45" == 37);
    static assert(octal!"0" == 0);
    static assert(octal!"7" == 7);
    static assert(octal!"10" == 8);
}

Then we can deprecate octal constants by ruling integral literals starting with 0 illegal.

The code above has a few problems, e.g. hardcoding of "ulong" but they can be easily solved by using and parsing the customary encodings (U, L, UL) at the end of the string.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=2656



--- Comment #6 from Andrei Alexandrescu <andrei@metalanguage.com> 2010-03-12 09:34:50 PST ---
(In reply to comment #5)
> I have a simple suggestion - how about putting this in object.d:
> 
> template octal(string s)
> {
>     static assert(s.length > 0);
>     static assert(s[0] >= '0' && s[0] < '8',
>         "Incorrect character in octal constant: `" ~ s[0] ~ "'");
>     if (s.length == 1)
>     {
>         enum ulong octal = s[0] - '0';
>     }
>     else
>     {
>         enum ulong octal = (s[0] - '0') + 8 * octal!(s[1 .. $]);
>     }
> }
> 
> unittest
> {
>     static assert(octal!"45" == 37);
>     static assert(octal!"0" == 0);
>     static assert(octal!"7" == 7);
>     static assert(octal!"10" == 8);
> }
> 
> Then we can deprecate octal constants by ruling integral literals starting with 0 illegal.
> 
> The code above has a few problems, e.g. hardcoding of "ulong" but they can be easily solved by using and parsing the customary encodings (U, L, UL) at the end of the string.

Meh, I forgot to paste the tested code back from emacs:

template octal(string s)
{
    static assert(s.length > 0);
    static assert(s[0] >= '0' && s[0] < '8',
        "Incorrect character in octal constant: `" ~ s[0] ~ "'");
    static if (s.length == 1)
    {
        enum uint octal = s[0] - '0';
    }
    else
    {
        enum uint octal = 8 * (s[0] - '0') + octal!(s[1 .. $]);
    }
}

unittest
{
    static assert(octal!"45" == 37);
    static assert(octal!"0" == 0);
    static assert(octal!"7" == 7);
    static assert(octal!"10" == 8);
}

For now I changed the type of the constant to uint because that's the most frequent. Anyway, the message (and the good news) is: we have enough linguistic means to express octal constants, so we could dispense with the ancient error-prone notation and not worry about inventing new notation.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=2656



--- Comment #7 from bearophile_hugs@eml.cc 2010-03-12 10:45:19 PST ---
octal!"10"

- This is ugly looking;
- it's too much long to write & takes too much space;
- editors will need extra code to recognize that as a number and color it with
the color used for numbers;
- It can create a good number of templates and compile-time strings.

So I think this idea needs to be shot in the head.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=2656



--- Comment #8 from Andrei Alexandrescu <andrei@metalanguage.com> 2010-03-12 10:47:43 PST ---
(In reply to comment #7)
> octal!"10"
> 
> - This is ugly looking;

(a) subjective (for one, I find 0o or whatever way uglier)
(b) then all templates are ugly

> - it's too much long to write & takes too much space;

how many octal literals do you have in your code right now?

> - editors will need extra code to recognize that as a number and color it with the color used for numbers;

it's an editor issue

> - It can create a good number of templates and compile-time strings.

it's a compiler implementation issue; the template could embed a ctfe.

> So I think this idea needs to be shot in the head.

There is no solid argument against it above.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=2656



--- Comment #9 from bearophile_hugs@eml.cc 2010-03-13 04:22:57 PST ---
I agree that the "0o" prefix is not very readable.

What about using Octal!50 instead (no leading zero. No string)?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------