d的8进制

原文

auto w = 01777777777777777777777;

这样报错,用这:

auto w = std.conv.octal!1777777777777777777777;

说,整溢出.
这样会工作:

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

这样也可以:

auto w = octal!"1777777777777777777777UL";

我的问题,与实现:

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

有关.
无法想象为了覆盖decimalInteger>ulong.max的增强.还有命名问题:根据参数表示(十进制)还是函数(八进制)来命名参数?更好名字可能是octalLiteralDisguisedAsDecimalLiteral.
octal!<literal>和octal!"<literal>"看作可互换.
C风格的八进制认为太容易与十进制混淆;仅在串字面中支持.D仍然支持编译时通过std.conv.octal模板解释的八进制整数文面,如octal!167.未提及限制.

---

octal!123是模板,因此必须是有效D代码.你的整数不是有效的D代码,因此无法编译.有效整数则可编译.
只要结果数字合适,串版本就可保证工作,这是编译器应建议它的原因.但是不必取消支持常规整数.
也应更新规范文档.
天哪,非串版本实现很糟糕,CTFE不应这样.

我的观点是它不会为某些有效八进制字面编译.
我还没看过C标头包含的东西.它如何处理八进制字面?

它们实际上不是八进制字面.
实现是太复杂,讽刺的是,由于代码审查挑剔类型,但概念不是:它假装是八进制字面.这是方便方法,预计不适用于所有可能值,因而有串版.

八进制字面实际上在D解析器中处理得很好.甚至可从中得到有效的数字.语法仍完好无损.
但是编译器只是用该解析值来显示错误消息.
我希望ImportC使用相同代码,只是不显示错误.

assert(octal!0b1111001 == octal!0x79);
//编译,但没用.

另一个问题:

auto x1 = octal!17777777777;
auto x2 = octal!"17777777777";
pragma(msg, typeof(x1)); // long
pragma(msg, typeof(x2)); // int

你也可以:

int x1 = octal!17777777777;

但是auto很方便,模板IFTI不会继承赋值给int等的能力.
我们只是不记录(但不弃用)数字版.一旦编译器建议停止使用,就不要用了.