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






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








 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



*** 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




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



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




09:34:50 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.


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




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




10:47:43 PST ---


 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




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




07:01:53 PST ---


 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                    |







 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




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



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


an urge to kill it with fire. I'd be sad to see them go. I like disco music,
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                     |



18:49:55 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


 an urge to kill it with fire. I'd be sad to see them go. I like disco music,
 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






 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



2010-11-27 19:56:52 PST ---


 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


 an urge to kill it with fire. I'd be sad to see them go. I like disco music,
 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




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






 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




09:53:36 PST ---


 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



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



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