d的符浮.

显式源和目标类型的强制转换来解决

auto cast_from(From,To,Real)(Real a)
{
    static if (is (From==Real))
        return cast(To) a;
    else
        pragma(msg, "错误类型");
}

void main()
{
    import std.range, std.stdio;

    short a=1;
    int b=cast_from!(short,int)(a);

    bool c=1;
    // int d=cast_from!(short,int)(a);
// 编译时错误

    writeln("测试: ", b);
}

D规则给C的规则加了些约束,来防止隐式转换导致精度丢失.
表明,为了性能,你肯定希望按单独代码单元对待UTF-8.
我痛苦发现,Unicode联盟使得无兆字节库就不可能做"正确"的Unicode.
D字符唯一问题是自动解码,讽刺的是,它符合你的建议,按Unicode代码点而不是代码单元对待一切.
这是个好主意,但它根本行不通.

gcc和ldc2编译器可转换?:至后者,而不是手写.

在D中,char是UTF-8,而ASCII是UTF-8的子集.

你不愿意写:

a += (b < c);

我愿意.而且,正如我之前所说,GPU喜欢该编码风格,SIMD代码也如此,加密代码也如此.
判断发生什么的唯一方法是转储生成的汇编程序.编写可在各种SIMD指令集间移植的矢量代码时尤其麻烦.它根本无法扩展.
manu编写矢量代码.
因此,D方法是不同的.可在D中编写向量代码.如果不编译到目标指令集,不会用仿真代替它.它发出错误信号.使用户可轻松地使用版本控制来调整表达式,来匹配目标平台向量能力.

总之,如果想要输出流中的特定指令插件,系统编程语言必须可表达所需插件.而不能依赖未记录和不一致的编译器转换.

import std.stdio;
import std.string;
import std.utf;

char char_tolower_bright (char c)
{
   if ('A' <= c && c <= 'Z')
      c = c | 0x20;
   return c;
}

string tolower_bright (string s)
{
   string t;
   foreach (c; s.byCodeUnit)
      t ~= c.char_tolower_bright;
   return t;
}

void process_strings (string s)
{
   writefln!"input            : %s" (s);
   auto t = s.tolower_bright;
   writefln!"bright           : %s" (t);
   auto u = s.toLower;
   writefln!"toLower (std.utf): %s" (u);
}

void main ()
{
   process_strings ("A a");
   process_strings ("A a");
}

除非使用配置文件引导优化编译,否则编译器一切都是盲目的.如分配寄存器和溢出位置.
如,现在和过去的AMD处理器已经在更多更小的执行单元方面模拟了更广泛的SIMD.
我同意,尽管即使在X86上,D也与有趣的指令严重不同步.除非使用内联asm(或Guillaume的内在函数库),否则不能用它们.
对非x86世界,ARM有NEON,但未来是SVE2,这些是变宽矢量指令.这可适合D_SIMD范式,但需要大小只有下限的类型.
RISC-V向量ISA类似发展.

如果优化器无法看穿具2个常量的三元表达式,则它可能需要更新.