www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - More octal questions

reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
OK, so I know that octals are deprecated, and the compiler will refuse
to compile code with octals unless the -deprecated flag is used.

But I find that std.datetime has literals of the form 000, 01, 02, 03,
and so on. Are these considered OK? Should my lexer accept them?


T

-- 
To err is human; to forgive is not our policy. -- Samuel Adler
Feb 14 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 02/14/2012 10:24 PM, H. S. Teoh wrote:
 OK, so I know that octals are deprecated, and the compiler will refuse
 to compile code with octals unless the -deprecated flag is used.

 But I find that std.datetime has literals of the form 000, 01, 02, 03,
 and so on. Are these considered OK? Should my lexer accept them?


 T

Yes. On 02/11/2012 05:37 PM, Timon Gehr wrote:
 Octal literals whose value is larger than 7 must be rejected. Octal literals
with values up to 7 must be accepted.

Feb 14 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 02/15/2012 09:30 AM, Andrej Mitrovic wrote:
 Where do you see those literals? I'm only seeing strings.

Line 8322: _assertPred!"=="(SysTime.fromISOString("20101222T172201"), SysTime(DateTime(2010, 12, 22, 17, 22, 01)));
Feb 15 2012
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
On 15/02/2012 16:41, Jonathan M Davis wrote:
<snip>
 They're not left over at all, and they have nothing to do with octal.

They are something to do with octal: because in D an integer literal beginning with 0 is defined to be octal, the compiler must interpret them as such if it is going to accept them at all. Of course, under current D2 without -d, the compiler rejects zero-led integer literals greater than 07. But it's because of this octal legacy that it accepts up to 07 but not 08, 09 or 010. Still, what's the long-term plan? To remove octal literals completely, and allow decimal literals to have leading 0s? Or to continue to allow just up to 07 until the end of time? Stewart.
Feb 15 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Where do you see those literals? I'm only seeing strings.
Feb 15 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Feb 15, 2012 at 02:42:04PM +0100, Timon Gehr wrote:
 On 02/15/2012 09:30 AM, Andrej Mitrovic wrote:
Where do you see those literals? I'm only seeing strings.

Line 8322: _assertPred!"=="(SysTime.fromISOString("20101222T172201"), SysTime(DateTime(2010, 12, 22, 17, 22, 01)));

That unittest contains a lot of these literals. I'm not sure if this is leftover from older code? T -- What's a "hot crossed bun"? An angry rabbit.
Feb 15 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, February 15, 2012 08:32:55 H. S. Teoh wrote:
 On Wed, Feb 15, 2012 at 02:42:04PM +0100, Timon Gehr wrote:
 On 02/15/2012 09:30 AM, Andrej Mitrovic wrote:
Where do you see those literals? I'm only seeing strings.

Line 8322: _assertPred!"=="(SysTime.fromISOString("20101222T172201"), SysTime(DateTime(2010, 12, 22, 17, 22, 01)));

That unittest contains a lot of these literals. I'm not sure if this is leftover from older code?

They're not left over at all, and they have nothing to do with octal. It's simply a matter of the natural thing for me to do when dealing with dates and times is to put the 0 in front of single digit numbers. You'll note that in the string representations, you _have_ to (per the ISO standard). So, I ended up doing it with the integer literals without thinking about it. - Jonathan M Davis
Feb 15 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Feb 15, 2012 at 08:41:33AM -0800, Jonathan M Davis wrote:
[...]
 They're not left over at all, and they have nothing to do with octal.
 It's simply a matter of the natural thing for me to do when dealing
 with dates and times is to put the 0 in front of single digit numbers.
 You'll note that in the string representations, you _have_ to (per the
 ISO standard). So, I ended up doing it with the integer literals
 without thinking about it.

Yes, I guessed as much. Which brings up a question of what exactly octal deprecation will entail. Seems like it would make sense to allow initial 0's in decimal literals once octal literals are phased out. Also, string escape sequences appear to allow backslash octal as well; are these being deprecated or are they here to stay? T -- Тише едешь, дальше будешь.
Feb 15 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 15 February 2012 at 17:48:03 UTC, H. S. Teoh wrote:
 Yes, I guessed as much. Which brings up a question of what 
 exactly octal deprecation will entail.

The goal here is to make sure things either do what they look like, or don't compile. 010 doesn't do what it looks like to a person used to decimal; it is a C octal literal for decimal 8. So it is deprecated. But, making it mean decimal 10 is also a no go, because if you're used to C syntax, it won't do what you expect. That's why it is an error. It is sure to confuse *somebody*. 01, 02, 03, ... 07 though work in both cases, so they might still be allowed. (I'm not sure if they are or not). But since there's no confusion for decimal people or for C people, there's no problem with those small numbers.
 Also, string escape sequences appear to allow backslash octal 
 as well;
 are these being deprecated or are they here to stay?

I'm not sure.
Feb 15 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Feb 15, 2012 at 06:52:09PM +0100, Adam D. Ruppe wrote:
[...]
 The goal here is to make sure things either do what they
 look like, or don't compile.
 
 010 doesn't do what it looks like to a person used to
 decimal; it is a C octal literal for decimal 8.
 
 So it is deprecated.
 
 But, making it mean decimal 10 is also a no go, because
 if you're used to C syntax, it won't do what you expect.
 
 That's why it is an error. It is sure to confuse *somebody*.

True. Especially if a C coder tries calling chmod() with 0644 and it silently gets interpreted as decimal.
 01, 02, 03, ... 07 though work in both cases, so they
 might still be allowed. (I'm not sure if they are or not).

Currently the compiler accepts them (even without -deprecated). Otherwise std.datetime wouldn't compile. :) T -- Bomb technician: If I'm running, try to keep up.
Feb 15 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, February 15, 2012 18:52:09 Adam D. Ruppe wrote:
 On Wednesday, 15 February 2012 at 17:48:03 UTC, H. S. Teoh wrote:
 Yes, I guessed as much. Which brings up a question of what
 exactly octal deprecation will entail.

The goal here is to make sure things either do what they look like, or don't compile. 010 doesn't do what it looks like to a person used to decimal; it is a C octal literal for decimal 8. So it is deprecated. But, making it mean decimal 10 is also a no go, because if you're used to C syntax, it won't do what you expect. That's why it is an error. It is sure to confuse *somebody*. 01, 02, 03, ... 07 though work in both cases, so they might still be allowed. (I'm not sure if they are or not). But since there's no confusion for decimal people or for C people, there's no problem with those small numbers.

Arguably more import is the fact that making 010 mean 10 would be a problem for porting code from C/C++. In general, C/C++ is either valid D code with the same semantics, or it doesn't compile (though there are a few exceptions - e.g. static arrays being value types). Treating 010 as 10 would violate that. So, I'd be very surprised if Walter agreed to do that. It'll just permanently stay an error like it is now. - Jonathan M Davis
Feb 15 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, February 16, 2012 00:38:10 Stewart Gordon wrote:
 On 15/02/2012 16:41, Jonathan M Davis wrote:
 <snip>
 
 They're not left over at all, and they have nothing to do with octal.

<snip> They are something to do with octal: because in D an integer literal beginning with 0 is defined to be octal, the compiler must interpret them as such if it is going to accept them at all. Of course, under current D2 without -d, the compiler rejects zero-led integer literals greater than 07. But it's because of this octal legacy that it accepts up to 07 but not 08, 09 or 010.

They have nothing to do with octal in that they were not intentionally octal. I was merely using the leading 0 without thinking about it, because having leading 0s generally makes more sense when dealing with the date/time stuff. The fact that they were octal is incidental. They result in the same number either way, save for 08 and 09 not working.
 Still, what's the long-term plan? To remove octal literals completely, and
 allow decimal literals to have leading 0s? Or to continue to allow just up
 to 07 until the end of time?

I expect that we will never allow decimal literals with leading 0s which would end up with different numbers than they would if we supported octal literals, because otherwise any C/C++ code which is ported to D and uses octal literals will then compile with different semantics, and that's generally verboten in D (there are a few exceptions, but they're quite rare). I'm not aware of Walter actually having stated what his longterm plan is though. - Jonathan M Davis
Feb 15 2012
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, February 16, 2012 00:38:10 Stewart Gordon wrote:
 On 15/02/2012 16:41, Jonathan M Davis wrote:
 <snip>
 
 They're not left over at all, and they have nothing to do with octal.

<snip> They are something to do with octal: because in D an integer literal beginning with 0 is defined to be octal, the compiler must interpret them as such if it is going to accept them at all.

They have nothing to do with octal in that they were not intentionally octal. I was merely using the leading 0 without thinking about it, because having leading 0s generally makes more sense when dealing with the date/time stuff. The fact that they were octal is incidental. They result in the same number either way, save for 08 and 09 not working.
 
 Still, what's the long-term plan? To remove octal literals completely, and
 allow decimal literals to have leading 0s? Or to continue to allow just up
 to 07 until the end of time?
 
 Stewart.

Feb 17 2012
parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.508.1329531876.20196.digitalmars-d-learn puremagic.com...
 They have nothing to do with octal in that they were not intentionally 
 octal.
 I was merely using the leading 0 without thinking about it, because having
 leading 0s generally makes more sense when dealing with the date/time 
 stuff.
 The fact that they were octal is incidental. They result in the same 
 number
 either way, save for 08 and 09 not working.

While we can't ever allow leading zeroes in the general case, to catch errors porting ocal literals from c family languages, 08 and 09 could actually be supported in the future.
Feb 17 2012