Walter Bright wrote:
> Stewart Gordon wrote:
>> Walter Bright wrote:
>> <snip>
>>> The octal literals are done the way C does them. The reason they are there are for when translating C code to D code, obscure bugs are not introduced.
>>
>> How would making them illegal not achieve this aim?
> 
> The only point to making them illegal would be to eventually remove them completely, which puts us back to \00 meaning something different in D than in C.

The "Obscure bugs during translation from C" argument presumes that such errors are more likely than ones such as:

int powersOfTen[] = {
  0001, //okay
  0010, // error: this is 8, not 10
  0100, // error: this is 64, not 100
  1000, // okay
};

and what the heck does "\000000\000000000\000\0000" mean?
I doubt there is much extant C code which uses octal. Automated translations of octal literals can be done accurately, and you're even supplying the 'htod' converter!

Note that C# doesn't have octal literals, but does include \0. So there's a precedent for dropping them. This also means that right now, converting code from C# to D can also introduce obscure bugs. I'd argue that that's a scenario that is at least as likely as bugs from C.

I think the argument for octal is very, very weak.

Reply to don,


> I think the argument for octal is very, very weak.
> 

OTOH even if I grant that, I don't see much reason for dropping them.

Don wrote:
> and what the heck does "\000000\000000000\000\0000" mean?

It doesn't matter, because if you're translating C code to D, the code is probably correct even if you don't know what it means.

> I doubt there is much extant C code which uses octal. Automated translations of octal literals can be done accurately, and you're even supplying the 'htod' converter!

htod is not intended for creating implementation source code. It's just for headers. I expect most C translations will be done by hand.


> Note that C# doesn't have octal literals, but does include \0. So there's a precedent for dropping them. This also means that right now, converting code from C# to D can also introduce obscure bugs. I'd argue that that's a scenario that is at least as likely as bugs from C.

It is a good point, but I don't see people translating C# to D. But I do see translating C to D (I do it myself!).

> I think the argument for octal is very, very weak.

The issue is really the cost of it being in vs the benefit of pulling it out. I see very little cost of leaving it in, so it doesn't need much benefit to make it worthwhile.

Reply to Walter,

> It is a good point, but I don't see people translating C# to D. But I
> do see translating C to D (I do it myself!).
> 

I am working with a ~11KLOC c# code base and a tool to automatically translate it to D

"I had a problem, I decided to solve it with reg-ex, not I have 200 problems" <g>

BCS wrote:
> Reply to Walter,
> 
>> It is a good point, but I don't see people translating C# to D. But I
>> do see translating C to D (I do it myself!).
>>
> 
> I am working with a ~11KLOC c# code base and a tool to automatically translate it to D

Color me wrong, then!

Hello Walter,

> BCS wrote:
> 
>> Reply to Walter,
>> 
>>> It is a good point, but I don't see people translating C# to D. But
>>> I do see translating C to D (I do it myself!).
>>> 
>> I am working with a ~11KLOC c# code base and a tool to automatically
>> translate it to D
>> 
> Color me wrong, then!
> 

Not to far off, you just forgot to qualify it with "sane".

That said, D is a lot like c#, near enough that most things in console apps translate well.

We have plans to release the translator "at some point".

BCS wrote:
> We have plans to release the translator "at some point".

That'll be cool!

Walter Bright wrote:
> Don wrote:
>> and what the heck does "\000000\000000000\000\0000" mean?
> 
> It doesn't matter, because if you're translating C code to D, the code is probably correct even if you don't know what it means.

Note that in C, you can't reasonably have \0 embedded in a string. But in both D and C# you can. So the "\0000" case isn't really a problem for C. It's far more likely in D that someone would write:
"1st\02nd\03rd\04th\0";
and expect it to work.

>> I doubt there is much extant C code which uses octal. Automated translations of octal literals can be done accurately, and you're even supplying the 'htod' converter!
> 
> htod is not intended for creating implementation source code. It's just for headers. I expect most C translations will be done by hand.

The point is that a reasonable fraction of the few remaining instances of octal literals, will be machine translated, and will therefore be free from these errors.

> 
>> Note that C# doesn't have octal literals, but does include \0. So there's a precedent for dropping them. This also means that right now, converting code from C# to D can also introduce obscure bugs. I'd argue that that's a scenario that is at least as likely as bugs from C.
> 
> It is a good point, but I don't see people translating C# to D. But I do see translating C to D (I do it myself!).
> 
>> I think the argument for octal is very, very weak.
> 
> The issue is really the cost of it being in vs the benefit of pulling it out. I see very little cost of leaving it in, so it doesn't need much benefit to make it worthwhile.

Inertia is the strongest argument, I think.
Octal-related bugs may occur
(1) when translating from ancient C code, if octal is removed.
(2) when translating from C#, if octal is retained.
(3) when writing new D code, if octal is retained.

IMHO, (2) and (3) are more probable than (1). However, all 3 cases are quite unlikely. It's extremely low on the list of priorities.