www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 2656] New: Require 0o format for octal literals

reply d-bugmail puremagic.com writes:
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.


-- 
Feb 13 2009
next sibling parent d-bugmail puremagic.com writes:
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_.


-- 
Feb 13 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
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. --
Feb 18 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Mar 12 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Mar 12 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Mar 12 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Mar 12 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Mar 12 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Mar 12 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Mar 13 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2656



--- Comment #10 from Andrei Alexandrescu <andrei metalanguage.com> 2010-03-13
07:01:53 PST ---
(In reply to comment #9)
 I agree that the "0o" prefix is not very readable.
 
 What about using Octal!50 instead (no leading zero. No string)?

Unfortunately that would preclude expressing large numbers in octal. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 13 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2656


Don <clugdbug yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Require 0o format for octal |Remove octal literals
                   |literals                    |


--- Comment #11 from Don <clugdbug yahoo.com.au> 2010-03-13 12:19:22 PST ---
(In reply to comment #10)
 (In reply to comment #9)
 I agree that the "0o" prefix is not very readable.
 
 What about using Octal!50 instead (no leading zero. No string)?

Unfortunately that would preclude expressing large numbers in octal.

I don't think it matters what we do. The point is, octal literals are *extremely* obscure, and don't need to be in the core language, especially with such a subtle, bug-prone syntax. If we agree to remove them from the core language, decision about the syntax should be treated the same as any other standard library syntax issue. It's not urgent to decide library naming issues right now. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 13 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2656



--- Comment #12 from Andrei Alexandrescu <andrei metalanguage.com> 2010-03-13
13:02:23 PST ---
Well put, Don!

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 13 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2656


bearophile_hugs eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX


--- Comment #13 from bearophile_hugs eml.cc 2010-03-25 17:59:51 PDT ---
After a too much long discussion Walter has said:

I admit it, I just like octal constants. I like the way they look. I don't feel

too, despite it being definitely out of style.< So probably octal literals will not go away. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 25 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2656


Andrei Alexandrescu <andrei metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |


--- Comment #14 from Andrei Alexandrescu <andrei metalanguage.com> 2010-03-25
18:49:55 PDT ---
(In reply to comment #13)
 After a too much long discussion Walter has said:
 
I admit it, I just like octal constants. I like the way they look. I don't feel

too, despite it being definitely out of style.< So probably octal literals will not go away.

Let's give it a hope. Facts and reason do have to carry some weight. I'll commit octal to Phobos. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 25 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2656



--- Comment #15 from bearophile_hugs eml.cc 2010-11-27 14:25:07 PST ---
(In reply to comment #14)
 Let's give it a hope. Facts and reason do have to carry some weight. I'll
 commit octal to Phobos.

Even MISRA C disallows octal constants. They are useful only in special situations. If Walter can't accept the idea of removing them from D, then an alternative idea is to use a strategy inspired by how GCC deals with trigraphs. This is a C program: #include "stdio.h" int main() { puts("??-"); return 0; } If I compile it with GCC 4.5 I receive: ...>gcc tritest.c -o tritest tritest.c: In function 'main': tritest.c:3:11: warning: trigraph ??- ignored, use -trigraphs to enable ...>tritest ??- But a compiler switch enables them: ...>gcc -trigraphs tritest.c -o tritest ...>tritest ~ A similar compiler switch like "-octals" may enable octal number syntax in D. But the idea of numerical constants that change value according to a compiler switch is bad, so I don't want a warning. So a better idea is to turn integral literals that start with one zero into true syntax errors, unless the "-octals" switch is used. This is useful also because turns standard C syntax (octals) into a syntax error, instead of turning them silently into different values. This follows the D design strategy of behaving (almost everywhere) like C where the C syntax is accepted by the D compiler and producing a syntax error otherwise. (This is not a tidy solution, but keeping some backwards compatibility with C often asks for not tidy workarounds). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 27 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2656


Unknown W. Brackets <bugs-d unknownbrackets.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugs-d unknownbrackets.org


--- Comment #16 from Unknown W. Brackets <bugs-d unknownbrackets.org>
2010-11-27 19:56:52 PST ---
(In reply to comment #13)
 After a too much long discussion Walter has said:
 
I admit it, I just like octal constants. I like the way they look. I don't feel

too, despite it being definitely out of style.< So probably octal literals will not go away.

Not that I like octal literals, but they are still used by some. I've definitely seen things like 0775 etc. (even though or'd constants should be used.) Especially in quick scripts that rdmd was created for. I think changing its syntax, just like D did with ~, makes a lot of sense. Removing it will probably only manage to annoy *someone*. As for octal!"editor" - why not have imaginary!"1i + 2"? In fact, why have this 1_000 or 5L nonsense, those should be templates that take strings too. Saying things are "editor problems" and not caring any further is exactly the way to create a bad language. People use editors and languages together, not apart. Creating a feature that's easy for the language developer but terrible for the editor and therefore the end-user is, well, silly at best. Just IMHO. -[Unknown] -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 27 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2656



--- Comment #17 from Andrei Alexandrescu <andrei metalanguage.com> 2010-11-28
08:40:41 PST ---
I wonder what people's experience with octal has been.

http://www.digitalmars.com/d/2.0/phobos/std_conv.html#octal

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 28 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2656



--- Comment #18 from bearophile_hugs eml.cc 2010-11-28 08:50:33 PST ---
(In reply to comment #17)
 I wonder what people's experience with octal has been.
 
 http://www.digitalmars.com/d/2.0/phobos/std_conv.html#octal

I have never had to use octals in D code so far, so I have no experience on that "octal". -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 28 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2656



--- Comment #19 from Sobirari Muhomori <dfj1esp02 sneakemail.com> 2010-11-28
09:53:36 PST ---
(In reply to comment #0)
 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.

Haha, this printf argument is laughable. With printf %#x will prepend 0x prefix to hex number, you can't do this for octal and binary numbers. I think, 0o775 is ok (you can see it just here). He has a good point that it's leading zero that signals "something nice is here" and size of o is enough to figure out, what is this. 0c is just a syntactical hack in attempt to not use 0o. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 28 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2656


kennytm gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kennytm gmail.com


--- Comment #20 from kennytm gmail.com 2011-04-03 07:50:02 PDT ---
RESOLVED-FIXED?

https://github.com/D-Programming-Language/dmd/commit/87afe713711060ec73942d1a94d3e28024781932

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 03 2011
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2656


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
                 CC|                            |bugzilla digitalmars.com
         Resolution|                            |FIXED


--- Comment #21 from Walter Bright <bugzilla digitalmars.com> 2011-04-03
17:31:13 PDT ---
Octal literals now deprecated, use std.conv.octal instead.

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