auto w = 01777777777777777777777;

Error: octal literals `01777777777777777777777` are no longer supported, use `std.conv.octal!1777777777777777777777` instead

It's worth a try:

auto w = std.conv.octal!1777777777777777777777;

Error: integer overflow

Quote from std/conv.d:

template octal(alias decimalInteger)
if (is(typeof(decimalInteger)) && isIntegral!(typeof(decimalInteger)))
{
    enum octal = octal!(typeof(decimalInteger))(to!string(decimalInteger));
}

Does it feel wrong to you, too?

On Wednesday, 6 April 2022 at 20:27:10 UTC, kdevel wrote:

Yes. I've changed to hint s.t. it suggests the string version. PR

On Thursday, 7 April 2022 at 12:52:20 UTC, MoonlightSentinel wrote:

Commendable, but my question related to the implementation

template octal(alias decimalInteger)
if (is(typeof(decimalInteger)) && isIntegral!(typeof(decimalInteger)))
{
    enum octal = octal!(typeof(decimalInteger))(to!string(decimalInteger));
}

For this code I can hardly imagine an enhancement in order to cover decimalInteger > ulong.max. There is also a naming issue: Do we name parameters after their representation (decimal) or after their function (octal)? A better name is probably octalLiteralDisguisedAsDecimalLiteral.

The documentation [1], [2] does not explicitly mention the inherent limitation of the quoteless conversion. The two forms octal!<literal> and octal!<literal>" are treated as interchangeable. In [3] we read

4. C-style octal integer notation was deemed too easy to mix up with decimal notation; it is only fully supported in string literals. D still supports octal integer literals interpreted at compile time through the std.conv.octal template, as in octal!167.

There is no mention of any restriction of the argument domain at all.

TL;DR: Deprecate and remove template octal(alias decimalInteger).

[1] https://dlang.org/library/std/conv/octal.html
[2] https://dlang.org/phobos/std_conv.html#octal
[3] https://dlang.org/spec/lex.html#integerliteral

On 4/7/22 10:00 AM, kdevel wrote:

octal!123 is a template, and as such, must be valid D code. Your integer is not valid D code, so it doesn't compile. That doesn't mean it won't compile for valid integers.

The string version is guaranteed to work, as long as the resulting number fits, which is why it should be suggested by the compiler. But removing the support for regular integers isn't necessary.

A spec documentation update would be good too.

And OMG, that implementation for the non-string version is terrible, we should not be doing that for CTFE.

-Steve

On Thursday, 7 April 2022 at 15:01:02 UTC, Steven Schveighoffer wrote:

That was never disputed.

That was not my objection. My point is that it won't compile for certain valid octal literals. Consider this implementation

template octal(ubyte decimalInteger)
{
    enum octal = octal!(typeof(decimalInteger))(to!string(decimalInteger));
}

Your argument applies to this code accordingly. But you would certainly halt it in the code review. Does it really make a qualitative difference if one writes ubyte or – as implicitly in the current code – ulong?

Stefan

BTW: I haven't yet taken a peek into the C header inclusion stuff. How are octal literals processed in that code?

On Thursday, 7 April 2022 at 16:28:39 UTC, kdevel wrote:

They're not actually octal literals.

The implementation is (ridiculously) overcomplicated - ironically, as a result of code review nitpicking types - but the concept isn't: it pretends it is an octal literal. This is a convenience method that is not expected to work for all possible values, which is why the string one exists.

Note, Adam already answered the other questions.

On 4/7/22 12:28 PM, kdevel wrote:

Octal literals are actually processed just fine in the D parser. You even get a valid number out of it. In fact, technically the grammar is all still there intact.

But then the compiler just uses that parsed value to display the error message.

I would expect ImportC to use the same code, and just not display the error.

-Steve

On 4/7/22 12:38 PM, Adam Ruppe wrote:

Yes. In fact, this compiles and is just... not useful.

assert(octal!0b1111001 == octal!0x79);

-Steve