変更ログ 2.079.0

dmd どの引数がパラメータにマッチしなかったかをエラーメッセージとともに表示するようになった。

void fill(ref char[16] buf, char c);

void main()
{
    fill("1234567890123456", '*');

    const char[16] s;
    fill(s, '*');
}

出力される:

fillchar.d(5): Error: function fillchar.fill(ref char[16] buf, char c) is not callable using argument types (string, char)
fillchar.d(5):        cannot pass rvalue argument "1234567890123456" of type string to parameter ref char[16] buf
fillchar.d(8): Error: function fillchar.fill(ref char[16] buf, char c) is not callable using argument types (const(char[16]), char)
fillchar.d(8):        cannot pass argument s of type const(char[16]) to parameter ref char[16] buf

注釈:現在のところ、この変更は関数にオーバーロードがある場合には適用されない。

カンマ式はしばしば混乱やバグの原因となってきた。 カンマ式の結果を使用するとエラーメッセージが表示されるようになった。

カンマ演算子(,)は、複数の式を実行し、最後に返された式以外の結果を破棄する。 の結果を破棄する。

int a = 1;
int b = 2;
bool ret = a == 2, b == 2; // true

また、カンマ演算子をforループのインクリメント文に使用することもよくある。 文でカンマ演算子を使うこともよくある。

for (; !a.empty && !b.empty; a.popFront, b.popFront)

従って、for-loopインクリメント文の中でカンマ演算子を使うことは、まだ許されている。

是正措置

可能であれば、カンマ演算子を2つの文に分割する。そうでない場合は ラムダを使用する。

auto result = foo(), bar();

// 2つの文に分割する
foo();
auto result = bar();

// またはラムダを使う
auto result = {foo(); return bar();}();

根拠:

カンマ演算子は意図しない動作につながる。 さらに、カンマ演算子は一般的に使用されておらず、カンマを使用した言語機能としてタプルを実装する能力を阻害している。 をカンマを使った言語機能として実装する能力を阻害する。

カンマ演算子の偶発的な使用による問題の抜粋:

writeln( 6, mixin("7,8"), 9 ); // 6, 8, 9

struct Vec
{
    this(T...)(T args) { ... }
}
// 型名がない
Vec v = (0, 0, 3); // Vec(3)

int a = 0;
int b = 2;
if (a == 1, b == 2) {
    // 常に到達する
}

void foo(int x, int y=0) {}
foo((a, b)); // おっと、foo(b)が呼び出された

synchronized (lockA, lockB) {}
// 複数式は現在実装されていないが、カンマ演算子によりコンパイルされる

可変長テンプレートパラメーターの後にデフォルト値を持つ関数パラメーターを置くことができるようになった。 IFTIが使用された場合、常にデフォルト値を取る。 これにより、以前は不可能であった可変長パラメータの後に特別なトークン(例:__FILE__ )を使用することができるようになった。

例:

string log(T...)(T a, string file = __FILE__, int line = __LINE__)
{
  return text(file, ":", line, " ", a);
}

assert(log(10, "abc") == text(__FILE__, ":", __LINE__, " 10abc"));

これは、以前の回避策よりも好ましい。 を呼び出してしまう:

string log(string file = __FILE__, int line = __LINE__, T...)(T a);

詳細は非推奨機能を参照のこと。

このリリースから、delete キーワードを使用すると、非推奨の警告が表示される。

代わりに、ユーザーは destroy 可能であれば core.memory.__delete最後の手段として

OSX の-dylib フラグの非推奨期間が終了した。

dmd -dylib awesome_d_library.d

共有ライブラリを生成するには、-shared フラグを使う:

dmd -shared awesome_d_library.d

DIP 1008はマージされ、experimental-dip1008 フラグでプレビューできるようになった:

void main() @nogc
{
    throw new Exception("I'm @nogc now");
}

rdmd -dip1008 app.d

このリリース以前は、@disable を使用せずに 関数を除外することは不可能だった。 __trait(compiles) を使用しなければ、false 関数を除外することができなかった。 が返される可能性があるため、あまり理想的ではなかった。

これで、メタプログラミング・コードにおいて、@disable 関数を正確に検出できるようになった、 を使って、__traits(isDisabled) 、オーバーロード・セットでも検出できる:

module runnable;

struct Foo
{
    import std.stdio;
    @disable static void foo() {__PRETTY_FUNCTION__.writeln;}
    static void foo(int v) {__PRETTY_FUNCTION__.writeln;}
    static void bar() {__PRETTY_FUNCTION__.writeln;}
    @disable static void bar(int v) {__PRETTY_FUNCTION__.writeln;}
}

void test(T)()
{
    foreach (member; __traits(allMembers, T))
        foreach (overload; __traits(getOverloads, T, member))
            static if (!__traits(isDisabled, overload))
    {
        static if (is(typeof(&overload) == void function()))
            overload();
        else static if (is(typeof(&overload) == void function(int)))
            overload(42);
    }
}

void main(){test!Foo;}

をプリントしている:

void runnable.Foo.foo(int v)
void runnable.Foo.bar()

シンボルの選択的インポートは、インポートされたシンボルがインポートされたモジュールで定義されているか、パブリックにインポートされている場合にのみ機能する。 がインポートされたモジュールで定義されているか、公にインポートされている場合にのみ機能するはずである。 コンパイラのバグにより、シンボルを選択的にインポートすることは、インポートされたシンボルがインポートされたモジュールで定義されているか、公にインポートされている場合にのみ機能する。 において、そのシンボルが私的にインポートされたモジュールで定義されている場合でも、選択的インポートは機能する。 インポートされたモジュールで定義されていても、シンボルの選択的インポートは機能する。

//a.d
int bar;

//b.d
import a;

//c.d
import b : bar;

上記のコードでは、非推奨メッセージが表示される。 bar という非推奨メッセージが表示される。 にインポートされているため、b にはアクセスできない。

デリゲートをモジュール・スコープで初期化できるようになった。これにより、13259に対する修正(結果としてICEをエラーにする)の効果が変更され、フォローが合法になった:

void delegate() bar = (){};

関数ポインターはデリゲートの関数に設定され、コンテキスト・ポインターはNULLに設定される。

これは(OSX 64での)ブレークチェンジである。

C++のname manglingの不規則な処理系定義: "のため、D's long/ulongを対応するname manglingと移植可能に一致させるのは困難だった。 D言語のlong/ulongを対応するC++コンパイラーに移植するのは難しかった。 C++コンパイラーと一致させるのは難しかった。

その代わりに、対応するC++コンパイラがint64_t/uint64_tをどのように処理するかに依存する。 に依存することで、D<=>C++とのインターフェイスのC++側がよりシンプルになる。

現在dmdがサポートしているプラットフォームでは、OSXの64ビットのマングリングだけが変更される。この場合 この場合は'm'から'y'になる。

注釈: int64_tとuint64_tはstdint.hで定義されている: int64_t および uint64_t は stdint.h で定義されている。

ローカル・プライベート・インポートを持つ構造体を実装する場合、VarDeclaration にインポートされたシンボルが存在すると、シンボルがリークされる。 インポートされたシンボルが VarDeclaration ステートメント内に存在するとリークされる。詳細と例: https://issues.dlang.org/show_bug.cgi?id=18219 を参照のこと。

プライベート・インポートのシンボルは、構造体スコープの外からは見えないようにする。 構造体体 "である。このようなケースに遭遇した場合、deprecationが発行されるようになった。 遭遇した

現在、ddocは実行中のテキストにおいて、ドキュメント化されているシンボルやモジュール、あるいはパラメータと一致する単語を自動的にハイライトする を自動的にハイライトする。 関数名" と一致する単語を自動的にハイライトする。 便利ではあるが、しばしば モジュール、"関数"、パラメーターの識別子が通常の単語と一致する場合、テキスト中の通常の単語がハイライトされる。 パラメータ識別子が通常の単語と重なっている場合、テキスト中の通常の単語が意図せずハイライトされてしまうことがあった。 そのため このため、この挙動を抑制するために、_ を単語の前に付ける方法が急増した。

現在では、この機能を完全にオプトアウトするための、より良い解決策が実装されている。 この機能は、DDOC_AUTO_PSYMBOL 、DDOC_AUTO_KEYWORD 、およびDDOC_AUTO_PARAM マクロによって、この機能を完全に無効にすることができるようになった。 テキストで自動的にハイライトされる。コードブロック内のモジュール名、関数名、パラメータ名は含まれない。 は含まれない。デフォルトでは、これらのマクロは単にDDOC_PSYMBOL 、 DDOC_KEYWORDやDDOC_PARAM にリダイレクトするだけだが、ユーザーはこれらのマクロを再定義して、単に単語そのものに展開するようにすることができる。 を再定義することができる:

DDOC_AUTO_PSYMBOL = $0
DDOC_AUTO_KEYWORD = $0
DDOC_AUTO_PARAM = $0

さらに、単語の前に_ を付けると、自動ハイライトが抑制される。 DDOC_AUTO_PSYMBOL_SUPPRESS マクロでラップされる。これは これは、自動強調表示を避けたいユーザーに、これらのアンダースコア接頭辞の出現箇所を見つける簡単な方法を提供するためである。 アンダースコアの接頭辞を見つける簡単な方法を提供するためである。 テキストから取り除くことができる。 例えば、このマクロを次のように再定義することができる。 のような、目につきやすく検索しやすいマクロに再定義することができる:

DDOC_AUTO_PSYMBOL_SUPPRESS = FIXME_UNDERSCORE_PREFIX 

という文字列を生成し、生成されたドキュメントを検索する。 FIXME_UNDERSCORE_PREFIX _ を検索し、対応するすべての を削除する。

コンパイラーは、すべてのextern(D) シンボルの前にアンダースコアを付けるように更新された。 アンダースコアを付けるようになった。これにより これにより、コンパイルされたコードがbinutilプログラムでより良く動作するようになる。 シンボルをデバッガ内で分離してリストできるようになる。

これはABIを破壊する変更であり、ライブラリを再コンパイルする必要がある。

HexStringリテラルは非推奨である。 代わりに std.conv.hexString代わりに

インポートされたモジュールをコマンドラインで指定されたかのようにコンパイラに扱わせるコマンドラインオプション-i を追加した。 このオプションは、名前に基づいてモジュールをインクルード/除外する「モジュール・パターン」も受け付ける。 例えば、以下のようにすると、foo.bar で始まるモジュールを除き、foo で始まる名前のすべてのモジュールをインクルードする:

dmd -i=foo -i=-foo.bar

-i というオプションは、それ自体で以下と等価である:

dmd -i=-std -i=-core -i=-etc -i=-object

JSON出力により多くのフィールドを含めるために、-Xi=<name> を追加した。現在、含めることができるフィールドは4つある:"compilerInfo"、"buildInfo"、"modules"、"semantics"である。

dmd -Xi=compilerInfo -Xi=buildInfo -Xi=semantics -Xi=modules

は次のようなJSONファイルを生成する:

{
  "compilerInfo" : {
    "binary" : "<filename-of-compiler-binary>",
    "version" : "<compiler-version>",
    "supportsIncludeImports" : true,
  },
  "buildInfo" : {
    "config" : "<config-filename>",
    "cwd" : "<cwd-during-build>",
    "importParths" : [
      "<import-path1>",
      "<import-path2>",
      // ...
    ]
  },
  "semantics" : {
    "modules" : [
      {
        "name" : "<module-name>",
        "file" : "<module-filename>",
        "isRoot" : true|false
      },
      // その他のモジュールオブジェクト...
    ]
  },
  "modules" : [
    // すべてのモジュールの構文データの配列
    // これは、-Xi=<field>オプションのない
    // JSONファイルに対して生成される配列と同じである
  ]
}

JSONが-Xi= オプションなしで生成された場合、古いフォーマットが使用される。 古いフォーマットは、新しい "modules"フィールドに表示されるデータと同じである。

また、少なくとも1つのJSONフィールドが提供されていれば、ソースファイルがなくてもコンパイラーを起動できるようになった。

dmd -Xi=compilerInfo

これは実験的なコマンドラインフラグであり、次のリリースで安定化する予定である。

を使ったラムダ関数の比較が可能になった。 __traits(isSame, lamda1, lambda2)を使って比較できるようになった。2つのラムダを正しく比較するには つのラムダを正しく比較するためには、以下の条件が満たされなければならない。 を満たす必要がある:

• ラムダ関数の引数はテンプレート化された関数であってはならない。 を持ってはならない。その他の引数型(basic、 ユーザー定義、テンプレート)がサポートされる。
• ラムダ関数本体は、単一の式(return 文なし)を含まなければならない。 この式には、数値、マニフェスト定数、列挙型値、および引数のみが含まれる。 式にローカル変数、関数呼び出し、return文が含まれている、 関数は比較不可能とみなされる。

これらの制限は、次のリリース・バージョンで解除されるかもしれない。

ラムダが比較不可能とみなされた場合、__traits(isSame, ...) 。 式は、それが使われた場合、他のどんなラムダが比較に使われたとしても、falseを返す。 を返す。

Windowsインストーラは、MinGW定義から構築されたプラットフォーム・ライブラリと、VC2010共有Cランタイムのラッパー・ライブラリを追加する。 VC2010 共有 C ランタイムのラッパー・ライブラリが追加された。COFF オブジェクトファイルを -m64 または-m32mscoff 、Visual Studioのインストールが検出されないか、または プラットフォーム・ライブラリが検出されない場合、これらのライブラリが置き換えとして使用される。マイクロソフトのリンカー が見つからない場合は、LLVM リンカの LLD が使用される。

DMDはランタイムからさらに切り離された。 DMDはランタイムからさらに切り離された。 これは これは、Dを新しいプラットフォームに段階的または部分的に移植したいユーザーにとって興味深いものである。 ベアメタルプラットフォームやリソースに制約のあるプラットフォームをターゲットにしているユーザーや、次のようなユーザーにとって興味深いものとなるだろう。 ランタイムなしで他の言語からDをライブラリとして使いたいユーザー。

このリリース以前は、ランタイム機能を使用しない単純なDアプリケーションをコンパイルしようとすると、コンパイラーは以下のようなエラーメッセージを出していた。 made no use of any runtime features, the compiler would have emitted a number object.dの欠落、Error クラスの欠落、TypeInfo 、 やModuleInfo の欠落など、多くのエラーが表示された。

このリリースから、他の言語から使用するライブラリを作成できるようになった。 そのライブラリを実装する.d ソース・ファイルと、空の ファイルだけが必要である。 空のobject.d ファイル

例1.

module object

module math;

extern(C) int add(int a, int b)
{
    return a + b;
}

dmd -conf= -lib math.d
size math.a
   text    data     bss     dec     hex filename
      0       0       0       0       0 math.o (ex math.a)
     20       0       0      20      14 math_1_129.o (ex math.a)

また、このリリースから、最小限のランタイム実装で非常に小さな実行ファイルを作成できるようになった。 を作成できるようになった。

例2

DMDは_d_run_main 、ユーザー定義関数を呼び出す。 main 関数を呼び出す。 DMDは、Cランタイムにリンクするg++ への呼び出しを自動的に生成する。

module object;

private alias extern(C) int function(char[][] args) MainFunc;
private extern (C) int _d_run_main(int argc, char** argv, MainFunc mainFunc)
{
    return mainFunc(null);  // 簡単にするために`void main()`を仮定している
}

module main;

void main() { }

dmd -conf= -defaultlib= -fPIC main.d object.d -of=main
size main
   text    data     bss     dec     hex filename
   1403     584      16    2003     7d3 main

Example 3

手動でmain 。 Cランタイムはない。

module object;

extern(C) void __d_sys_exit(long arg1)
{
    asm
    {
        mov RAX, 60;
        mov RDI, arg1;
        syscall;
    }
}

extern void main();
private extern(C) void _start()
{
    main();
    __d_sys_exit(0);
}

module main;

void main() { }

dmd -c -lib main.d object.d -of=main.o
ld main.o -o main
size main
   text    data     bss     dec     hex filename
     56       0       0      56      38 main

より高度なD機能(例:クラス、例外など)を使用するには、実行時実装コードが必要になる。 ランタイム実装コードが必要になるが、有償で実装することができる。

コンパイラーは10.9を使用し、OSX上のlibc++ とリンクするように更新された。 これは、古いバージョンのmacOSの共有libstdc++ ライブラリが、最新のXCodeに含まれるヘッダーとの互換性に問題があったためである。 に含まれるヘッダーとの互換性に問題があるためだ。

コンパイラーを実行するために最低限必要なバージョンは、Mac OS X Mavericks(10.9)になった。

仕様では、プライベート・メンバー は同じモジュール内からしか見えない。 このリリース以前は、バグのため、プライベート・メンバが他のモジュールから選択的にインポートされることで見えていた。 が他のモジュールから選択的にインポートされ、仕様に違反していた。 このリリースから、宣言されたモジュールの外からプライベート・メンバにアクセスすることはできなくなった。 の外部からプライベート・メンバーにアクセスすると、非推奨メッセージが表示される。

@safe 、配列上で.ptr を使用することの非推奨期間が終了した。 以下は非推奨ではなくエラーとなる:

@safe ubyte* oops(ubyte[] arr) {
    return arr.ptr;
}

代わりに&arr[0] :

@safe ubyte* oops(ubyte[] arr) {
    return &arr[0];
}

これはSafeDにのみ適用されることに注釈:@system コード.ptr はまだ使用できる:

@system ubyte* oops(ubyte[] arr) {
    return arr.ptr;
}

core.memory.__delete非推奨のdelete から簡単に移行できる。 __delete delete と全く同じように動作する:

bool dtorCalled;
class B
{
    int test;
    ~this()
    {
        dtorCalled = true;
    }
}
B b = new B();
B a = b;
b.test = 10;

__delete(b);
assert(b is null);
assert(dtorCalled);
// 想定しているが、注意が必要だ
assert(a !is null);

例えば、Posixプラットフォームでは単純に実行できる:

sed "s/delete \(.*\);/__delete(\1);/" -i **/*.d

ユーザーは次のことを好むべきだ。 object.destroyオブジェクトを明示的にファイナライズする を優先し core.memory.__deleteに頼るのは object.destroy が実行可能なオプションでない場合にのみ頼るべきである。

ランタイムは最初の使用時にGCを遅延的に初期化するようになり、GCを使用しないアプリケーションは初期化をスキップできるようになった。

テンプレート・パラメーターとして std.format.formatテンプレート・パラメータとして文字列を与えることで パラメータの型が正しいかどうかをコンパイル時にチェックできる:

import std.format : format;

auto s1 = format!"%d"(4); // 正常に動作
auto s2 = format("%d"); // 実行時例外
auto s3 = format!"%d"(); // コンパイル時のエラー

さて、このオーバーロードを使うことで、std.formatは結果の文字列の長さを推測することができる。 出力バッファへの再割り当ての回数を減らすことができる。 を減らすことができる。

import std.format : format;

auto s1 = format!"%02d:%02d:%02d"(10, 30, 50); // 8文字であることが確実である
auto s2 = format!"%s %d"("Error Code: ", 42); // 経験則から推測する

長いフォーマットの文字列は、この変更の恩恵を最も受ける。

std.conv.hexStringはubyteの配列ではなく、不変文字列リテラルを返すようになった。 これは これは、非推奨の x"deadbeef" 文字列リテラル構文に代わるものである。

この変更の利点は以下の通りである:

• ドキュメントとの動作の一貫性
• hexString テンプレートのインスタンスが生成されたオブジェクトファイルに表示されなくなった。
• 生成されたオブジェクトファイルからTypeInfo 、様々なdruntime関数への参照がなくなった。
• -betterC モードと互換性がある。

場合によっては、コードが配列であることに依存していた。 が問題を解決する:

// エラーになった:
enum ubyte[8] input = hexString!"c3 fc 3d 7e fb ea dd aa";

// キャストを追加して修正する:
enum ubyte[8] input = cast(ubyte[8]) hexString!"c3 fc 3d 7e fb ea dd aa";

以前は、.nullify がNullable!C で呼び出されたとき、C がクラスまたは で呼び出された場合、基底オブジェクトは.destroy関数を介して即座に破壊される。.destroy 関数を介して即座に破壊される。このため、 インスタンスの外部にオブジェクトへの参照が残っている場合にバグが発生していた。 Nullable :

class C
{
    int canary = 0xA71FE;
    ~this()
    {
        canary = 0x5050DEAD;
    }
}

auto c = new C;
assert(c.canary == 0xA71FE);

Nullable!C nc = nullable(c);
nc.nullify;
assert(c.canary == 0xA71FE); // これは失敗する

.nullify メソッドが修正され、クラスやインターフェイスのインスタンスに対して.destroy を呼び出さなくなった。 を呼び出さないように修正され、上記のコードは正しく動作するようになった。

std.algorithm.iteration.substituteが追加された。 r のすべての置換パターンが、その置換に置き換えられる:

import std.algorithm.comparison : equal;
import std.algorithm.iteration : substitute;

// 単一要素を代入する
assert("do_it".substitute('_', ' ').equal("do it"));

// 複数の単一要素を置換する
assert("do_it".substitute('_', ' ',
                           'd', 'g',
                           'i', 't',
                           't', 'o')
              .equal("go to"));

// サブレンジを置換する
assert("do_it".substitute("_", " ",
                          "do", "done")
              .equal("done it"));

// 置換はどのElementTypeに対しても機能する
int[] x = [1, 2, 3];
auto y = x.substitute(1, 0.1);
assert(y.equal([0.1, 2, 3]));
static assert(is(typeof(y.front) == double));

コンパイル時に置換パラメータがわかっている場合は、より高速な テンプレート・オーバーロードを使うことができる:

import std.algorithm.comparison : equal;
import std.algorithm.iteration : substitute;

// 範囲の部分範囲を置換する
assert("apple_tree".substitute!("apple", "banana",
                                "tree", "shrub").equal("banana_shrub"));

// 範囲内の要素を置換する
assert("apple_tree".substitute!('a', 'b',
                                't', 'f').equal("bpple_free"));

// 値を置換する
assert('a'.substitute!('a', 'b', 't', 'f') == 'b');

std.bigint.divModは商と余りの両方を一度に計算する:

void divMod(const BigInt dividend, const BigInt divisor, out BigInt quotient, out BigInt remainder) pure nothrow
{
auto a = BigInt(123);
auto b = BigInt(25);
BigInt q, r;

divMod(a, b, q, r);

assert(q == 4);
assert(r == 23);
assert(q * b + r == a);
}

std.bigint.getDigitは、ulongs またはuints BigInt の基礎となる表現を構成する。

import std.bigint;

auto a = BigInt("1000");
assert(a.getDigit(0) == 1000);

auto b = BigInt("2_000_000_000_000_000_000_000_000_000");
assert(b.getDigit(0) == 4584946418820579328);
assert(b.getDigit(1) == 108420217);

std.exception.enforceの動作を反映するようになった。 std.exception.enforceEx の動作を反映し、同名のテンプレートとして使用できるようになった:

import std.conv : ConvException;
alias convEnforce = enforce!ConvException;
assertNotThrown(convEnforce(true));
assertThrown!ConvException(convEnforce(false, "blah"));

この変更に伴い、「ヴェルディ・エスパニョーラ」は「ヴェルディ・エスパニョーラ」ではなく「ヴェルディ・エスパニョーラ」となった、 std.exception.enforceの厳密なスーパーセットである。 std.exception.enforceExであり、2.079では非推奨となる。

std.experimental.allを使うと、すべての Phobos モジュールを便利に使えるようになる。 をインポートできる:

import std.experimental.all;
void main()
{
    10.iota.map!log.sum.writeln;
}

短いスクリプトの場合、標準ライブラリからすべてのモジュールを取得するために、多くのインポートが必要になることが多い。 モジュールのインポートが必要になる。 このリリースでは、import std.experimental.all 、標準ライブラリ全体を一度にインポートすることができる。 を使うことができる。これは、高速なプロトタイピングやREPLに使用できる:

import std.experimental.all;
void main()
{
    6.iota
      .filter!(a => a % 2) // 0 2 4
      .map!(a => a * 2) // 0 4 8
      .tee!writeln
      .sum
      .writefln!"Sum: %d"; // 18
}

以前と同様、シンボルの衝突は、衝突のあるシンボルが使用された場合にのみ発生する。 この場合、静的インポートまたは リネームされたインポートを使うことができる。 を使えば、特定のシンボルを一意に選択できる。

のベースライン・コストは0.5秒未満である(システムによって異なる)。import std.experimental.all のベースラインコストは0.5秒未満(システムによって異なる)である。 このオーバーヘッドをさらに削減するための作業が進行中である。

Motivation:

アロケータへの参照を追跡しておく、 未定義の動作:" を引き起こさないようにする。

RCIAllocator 今後は、古いIAllocator インターフェースを使用する。 std.experimental.allocator.allocatorObjectを使うことができる。 RCIAllocator を使うことができる。

import std.experimental.allocator.mallocator : Mallocator;

RCIAllocator a = allocatorObject(Mallocator.instance);
auto b = a.allocate(100);
assert(b.length == 100);
assert(a.deallocate(b));

Motivation:

アロケータへの参照を追跡しておく、 未定義の動作:" を引き起こさないようにする。

RCISharedAllocator 今後は、古い ISharedAllocator インターフェイスを使用する。 std.experimental.allocator.sharedAllocatorObjectカスタム・アロケータから。 RCISharedAllocator を使うことができる。

import std.experimental.allocator.building_blocks.free_list : SharedFreeList;
import std.experimental.allocator.mallocator : Mallocator;

shared SharedFreeList!(Mallocator, chooseAtRuntime, chooseAtRuntime) sharedFL;
shared RCISharedAllocator sharedFLObj = sharedAllocatorObject(sharedFL);

auto b = sharedFLObj.allocate(100);
assert(b.length == 100);
assert(sharedFLObj.deallocate(b));

std.file.readTextをチェックするようになった。 をチェックするようになった。BOMが存在し それがUTF-8、UTF-16、またはUTF-32の場合、 std.file.readTextを検証する。 要求された文字列型とマシンのエンディアンにマッチするかどうかを検証する、 不一致の場合は std.utf.UTFExceptionがスローされる。 がスローされる。

BOMがない場合、またはBOMがUTF-8、UTF-16、UTF-32のいずれでもない場合、動作はこれまで通りであり、UTF検証は通常通り行われる。 UTFの検証は通常どおり行われる、 したがって、テキストが要求された文字列型に対して有効でない場合は std.utf.UTFExceptionがスローされる。

さらに、バッファが要求された文字列型にキャストされる前に、アライメントがチェックされる。 の配列では5バイトがきれいに収まらない。wchar やdchar )がチェックされる。 std.utf.UTFExceptionがスローされる。 がスローされるようになった。以前は アラインメントはキャストの前にチェックされなかったので、アラインメントが不一致の場合、キャストはエラーを投げていた、 がスローされ、プログラムが停止する。

std.parallelism.TaskPool.foldと機能的に等価である。 と同等の機能である。 パラメータが最初に来ることと、複数のシードに対して tupleを使う必要がない。

static int adder(int a, int b)
{
    return a + b;
}
static int multiplier(int a, int b)
{
    return a * b;
}

// 範囲のみ
auto x = taskPool.fold!adder([1, 2, 3, 4]);
assert(x == 10);

// 範囲とシード(以下0と1; この例では
// 複数の関数があることにも注意)
auto y = taskPool.fold!(adder, multiplier)([1, 2, 3, 4], 0, 1);
assert(y[0] == 10);
assert(y[1] == 24);

// 範囲、シード(0)、ワークユニットサイズ(20)
auto z = taskPool.fold!adder([1, 2, 3, 4], 0, 20);
assert(z == 10);

std.range.nullSinkの便利なラッパーである。 std.range.NullSink の便利なラッパーであり、受け取ったデータを破棄する出力レンジを作成する。これは /dev/nullのアナログである。

import std.csv : csvNextToken;

string line = "a,b,c";

// 最初の列を無視する
line.csvNextToken(nullSink, ',', '"');
line.popFront;

// 2列目を見る
Appender!string app;
line.csvNextToken(app, ',', '"');
assert(app.data == "b");

std.range.slideが追加された:

import std.array : array;
import std.algorithm.comparison : equal;

assert([0, 1, 2, 3].slide(2).equal!equal(
    [[0, 1], [1, 2], [2, 3]]
));
assert(5.iota.slide(3).equal!equal(
    [[0, 1, 2], [1, 2, 3], [2, 3, 4]]
));

assert(iota(7).slide(2, 2).equal!equal([[0, 1], [2, 3], [4, 5]]));
assert(iota(12).slide(2, 4).equal!equal([[0, 1], [4, 5], [8, 9]]));

// カスタムステップサイズを設定する(デフォルトは1)
assert(6.iota.slide(1, 2).equal!equal(
    [[0], [2], [4]]
));

assert(6.iota.slide(2, 4).equal!equal(
    [[0, 1], [4, 5]]
));

// ウィンドウサイズより小さい要素でのスライドを許可する
assert(3.iota.slide!(No.withPartial)(4).empty);
assert(3.iota.slide!(Yes.withPartial)(4).equal!equal(
    [[0, 1, 2]]
));

の新しいオーバーロード関数が追加された。 std.string.strip, std.string.stripLeftおよび std.string.stripRightの新しいオーバーロード関数は を受け付ける。

import std.string: stripLeft, stripRight, strip;

assert(stripLeft("www.dlang.org", "w.") == "dlang.org");
assert(stripRight("dlang.org/", "/") == "dlang.org");
assert(strip("www.dlang.org/", "w./") == "dlang.org");

以前は、基本型が文字列型の列挙型は、true であった。 std.traits.isSomeStringであり std.traits.isNarrowString. 時折、これは便利だったが、一般的にはバグの元だった。 というのも、文字列で動作するコードが、基本型が文字列の列挙型で動作するとは限らないからである。 というのも、文字列で動作するコードは、基本型が文字列である列挙型では必ずしも動作しないからである。 というのも、文字列を扱うコードは、基底型が文字列である列挙型を扱うとは限らないからだ。例えば stringを基本型とする列挙型は、false 。 std.range.primitives.isInputRange.そのため と std.traits.isSomeStringと std.traits.isNarrowStringをtrue 。

一部のコードにとっては、これは破壊的な変更になるだろうが、ほとんどのコードには影響がない。 ほとんどのコードは影響を受けないか、テンプレート制約のところで列挙型で失敗するだろう。 で失敗する。つまり、コードが壊れるリスクは最小だが、存在する。 他のコードは、!is(T == enum) のようなものをテンプレート制約から取り除くことができる。 テンプレート制約の一部である std.traits.isSomeStringそして std.traits.isNarrowStringの一部となったため、他のコードはテンプレート制約から のようなものを取り除くことができるようになった。 の一部となったため、他のコードはテンプレート制約から のようなものを取り除くことができるようになった。

を使用するコードは std.traits.isSomeStringまたは std.traits.isNarrowStringをテンプレート制約で使用し、他の を使用し、列挙型が制約を通過することを妨げるような他の条件を持たないが、もし列挙型がテンプレートに渡された場合、テンプレート内部でのコンパイルは失敗する。 もし列挙型がテンプレートに渡されると、テンプレート内部でのコンパイルに失敗する。 テンプレート制約のところでコンパイルに失敗する。そのため、このような のコードは壊れたのではなく、修正されたのだ。

これらの変更によって、まれに壊れるコードがある。 std.traits.isSomeStringまたは std.traits.isNarrowStringを使っているコードである。 を使用し、"列挙型"を通さないための他の条件を使用していないコードである。 を通さないようにする他の条件を使わず、実際に文字列とenumの両方でコンパイルするコードをテンプレートに持つコードである。 と列挙型の両方でコンパイルされるコードがある。そのようなコードは std.traits.OriginalType, std.conv.asOriginalTypeまたは std.traits.StringTypeOfを代わりに使うように変更する必要がある。例:列挙型に制約を渡す場合、 の代わりに

auto foo(S)(S str)
if (isSomeString!S)
{
    ...
}

コードは次のようになる。

auto foo(S)(S str)
if (isSomeString!(OriginalType!S))
{
    ...
}

経験則として、ジェネリックコードは暗黙的な変換を禁止し 呼び出し元が明示的に変換を行うように強制する(一般的に、これが最もエラーの起こりにくいアプローチである)。 これは一般的に最もエラーの起こりにくいアプローチである)、あるいは、関数内でパラメータが使用される前に目的の型への変換を強制する。 パラメータが関数で使用される前に、関数が目的の型に変換されるようにする。 関数が暗黙のうちに変換され、その結果動作するような型ではなく、確実に目的の型に対して動作するようにする。 その結果、引数が正確な型であろうと暗黙的に変換された型であろうと関係なく動作する。 正確な型か暗黙的に変換された型かに関係なく動作する。

しかし、暗黙的な変換の結果、パラメータをスライスしたり、アドレス を参照したりすることになる場合は、細心の注意が必要である。 パラメータをスライスするか、あるいはそのアドレスを参照することになる場合は、細心の注意が必要である。 ローカルメモリへの参照が"関数"をエスケープすることが非常に容易になるからである。 変換が呼び出し先で行われる場合、スライスは呼び出し先で行われる。 変換が呼び出し側で行われる場合、スライシングは呼び出し側で行われるため、関数が戻ってきても動的配列は有効である。 幸いなことに、文字列を基本型とする列挙型にはそのような問題はない。 暗黙的に動的配列に変換される他の型(静的配列など)にはこの問題がある。 に暗黙的に変換される他の型にはこの問題がある。 ジェネリック関数に暗黙の変換に基づく型を受け取らせないことが推奨される大きな理由である。

関数が文字列と暗黙的に文字列型に変換される型の両方を受け入れることを想定している場合は、明示的に文字列型を受け入れるようにすることを推奨する。 暗黙のうちに文字列型に変換される型の両方を受け付ける関数である場合は、明示的に動的配列を受け付けるが、要素型でテンプレート化されることを推奨する。 動的配列を受け付けるが、要素型はテンプレート化する。

auto foo(C)(C[] str)
if (isSomeChar!C)
{
    ...
}

こうすることで、暗黙の変換は呼び出し側で行われ、関数内部で@安全性の問題を引き起こすことはない。 関数の内部で安全性の問題を引き起こすことはない。また テンプレート制約が短くなり、理解しやすくなる。

標準ライブラリは、toString のオーバーロードを認識し、使用するように修正された。 を認識し使用するように修正された。 を認識し使用するように修正された。

import std.range.primitives;
import std.stdio;

struct MyType
{
    void toString(W)(ref W writer) if (isOutputRange!(W, char))
    {
        put(writer, "Custom toString");
    }
}

auto t = MyType();
writeln(t); // "Custom toString"と書く

これはユーザーにとっていくつかの利点がある。第一に、このデザインは。 toString(scope void delegate(const(char)[]) sink) 。 toString.のような関数の出力バッファに文字が配置されるためだ。 のような関数の出力バッファに配置されるためである。 std.format.format.第三に、、 toString がテンプレートになったため、推論によって@safe 。 をつけることができる。

これまでのtoString 。