Jump to page: 1 2
Thread overview
April 06
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?

April 06
On Wednesday, 6 April 2022 at 20:27:10 UTC, kdevel wrote:
> It's worth a try:
>
> ```
> auto w = std.conv.octal!1777777777777777777777;
> ```

The error message isn't smart enough to suggest this, but putting quotes around it ought to work.

auto w = std.conv.octal!"1777777777777777777777";

like that.

April 06
On 4/6/22 13:32, Adam D Ruppe wrote:

And with U or L as needed:

  auto w = octal!"1777777777777777777777UL";

Ali

April 07

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

>

Does it feel wrong to you, too?

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

April 07

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

>

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

>

Does it feel wrong to you, too?

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

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

  1. 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

April 07

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

>

The documentation does not explicitly mention the inherent limitation of the quoteless conversion. The two forms octal!<literal> and octal!<literal>" are treated as interchangeable.

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

April 07

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

>

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

>

The documentation does not explicitly mention the inherent limitation of the quoteless conversion. The two forms octal!<literal> and octal!<literal>" are treated as interchangeable.

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 was never disputed.

>

That doesn't mean it won't compile for valid integers.

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?

April 07

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

>

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

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.

April 07

Note, Adam already answered the other questions.

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

>

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

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

April 07

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

>

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

>

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

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.

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

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

-Steve

« First   ‹ Prev
1 2