F# 11 の新機能

F# 11へようこそ。 このリリースにより、ドメイン モデルを明確に区別し、汎用アルゴリズムを再利用し、非同期処理を調整し、コンパイラのメモリ使用量を削減できるようになります。

• レコード スプレッドは、ストレージ モデルとアプリケーション モデルに型の共有を強制することなく、フィールドを再利用します。
• ジェネリック アルゴリズムにおける拡張メンバーにより、既存の型はラッパーを使わずに操作を共有できるようになります。
• .NET統合では、デリゲートメタデータを保持し、APIドキュメントを再利用します。
• 非同期ヘルパーとタスク ヘルパーは、キャンセルを API の境界を越えて伝搬し、同時作業を制限します。
• コンパイラとライブラリの改善により、繰り返し行われる解析が減り、一部の割り当てを回避します。

これらの変更の背後にある提案、実装、レビュー、テストについて F# コミュニティに感謝します。 以下の特集には、共同作成者のリンクが掲載されています。

レコード スプレッド: 反復的なマッピングを伴わない区別されたモデル

ストレージ モデルとアプリケーション モデルを区別するために、レコード スプレッドは宣言を繰り返さずに共有フィールドを再利用します。 ここでは、モデルは顧客の詳細を共有しますが、さまざまな識別子の種類を使用します。

open System

type CustomerId = CustomerId of Guid

type CustomerDetails = { Name: string; PreferredLanguage: string }

type CustomerRow =
    { ...CustomerDetails
      Id: string
      InternalNote: string }

type Customer =
    { ...CustomerDetails
      Id: CustomerId }

...CustomerDetails はフィールドの宣言を追加します。 境界では、...row は変換が識別子を解析する間、値をコピーします。

let toCustomer (row: CustomerRow) =
    match Guid.TryParse row.Id with
    | true, id -> Ok ({ ...row; Id = CustomerId id }: Customer)
    | false, _ -> Error "Invalid customer identifier."

送信先は共有の詳細を保持し、Idを置き換え、InternalNoteを除外します。 Guid.TryParse (スプレッドではありません) が識別子を検証し、形式が正しくない入力が Error を生成します。

これはアプリケーション層マッピングの問題に対処します。 値のスプレッドでは、名前付きレコードと匿名レコードも組み合わせられます。型スプレッドでは、名前付きレコードのみが作成されます。 後のフィールドが優先され、ソースは順番に 1 回実行されます。 合成の例や、共有された要素が同時に変更、進化することに伴うリスクについては、レコード スプレッド オペレーターを参照してください。

スプレッドのレコードを提供いただいた @brianrourkeboll さんに感謝します。

ジェネリック アルゴリズム、演算子、タプルの拡張メンバー

既存の型間でアルゴリズムを共有するために、F# 11.2 では 、拡張メンバーが静的に解決された型パラメーター (SRTP) 制約を満たすことができます。 たとえば、1 つの変換で、ラッパー型のないリストとオプションを処理できます。

リストとオプション間で変換を共有する

ライブラリの map がスコープ内にある場合、アプリケーションはどちらの表現もクリーンアップしたり、要素の型を変更したり、変換を組み合わせたりすることができます:

let inline cleanNames values =
    map (fun (name: string) -> name.Trim().ToUpperInvariant()) values

let batch: string list = cleanNames [ " Ada "; " grace " ]
let optional: string option = cleanNames (Some " linus ")
let missing: string option = cleanNames (None: string option)
let lengths: int list = map String.length batch
let nested: int option list = map (map String.length) [ Some "abc"; None ]

printfn "%A; %A; %A" batch optional missing
printfn "%A; %A" lengths nested
// ["ADA"; "GRACE"]; Some "LINUS"; None
// [3; 5]; [Some 3; None]

Structural.Adaptersのアダプターは、新しいコンテナーを適用するのではなく、使い慣れた操作を使用します。

type List<'T> with
    static member Map(source: 'T list, mapping: 'T -> 'U) : 'U list =
        List.map mapping source

type Option<'T> with
    static member Map(source: 'T option, mapping: 'T -> 'U) : 'U option =
        Option.map mapping source

Structural.Algorithms の共有関数は、静的メンバー Map の入力型を問い合わせます:

let inline map (mapping: 'T -> 'U) (source: ^Input) : ^Output =
    (^Input :
        (static member Map: ^Input * ('T -> 'U) -> ^Output)
        (source, mapping))

^Input と ^Output は静的に解決される型です。 コンパイラは、各具象呼び出しで、必要な署名を持つメンバーを選択します。 これらの拡張機能は、インターフェースの実装を追加するものではありません。 アプリケーション全体は、両方のモジュールを開きます。

演算子、コンテキスト、および出力の種類

同じメカニズムで、 タプル演算子とコンテキスト伝達 と 出力指向の構築がサポートされます。 ネイティブのタプル ヘッダーでは、宣言時だけでなく、拡張関数の解決が行われる呼び出しサイトでも、F# 11.2 の機能が有効になっている必要があります。

別の機能追加である AllowOverloadOnReturnType を使用すると、1 つのファクトリ クラスで、戻り値によって区別されるオーバーロードを宣言できるようになります:

type Inject =
    [<AllowOverloadOnReturnType>]
    static member Pure(value: 'T) : 'T list = [value]

    [<AllowOverloadOnReturnType>]
    static member Pure(value: 'T) : 'T option = Some value

let batch: string list = Inject.Pure "ready"
let optional: string option = Inject.Pure "ready"
// ["ready"] and Some "ready"

この Core 11 属性にはプレビューは必要ありません。 結果注釈はオーバーロードを選択します。ない場合、呼び出しはあいまいなままです。 「戻り値の型で選択する」を参照してください。

@gusty による汎用プログラミング サポートの拡張に感謝します。

.NET統合と開発エクスペリエンス

直接デリゲートはハンドラーの実際のコントラクトを保持します

ハンドラー名とバインド属性をフレームワークに公開するために、F# 11 では、ラッパーではなく、互換性のある名前付き関数を直接ターゲットにすることができます。 これにより、ASP.NET Core Minimal API は、ルート、サービス、ヘッダーの契約を読み取ることができます:

open System
open Microsoft.AspNetCore.Builder
open Microsoft.AspNetCore.Mvc
open Microsoft.Extensions.DependencyInjection

type ShipmentStore() =
    member _.Status trackingId =
        if trackingId = "SHP-1042" then "Dispatched" else "Unknown"

let status
    (trackingId: string)
    ([<FromServices>] store: ShipmentStore)
    ([<FromHeader(Name = "X-Customer")>] customer: string) =
    $"{customer}: {trackingId} is {store.Status trackingId}"

let handler = Func<string, ShipmentStore, string, string>(status)

実行可能なプロジェクトと構築/互換性の規則を参照してください。 キャプチャと引数の適応には、ラッパーが引き続き必要な場合があります。

直接委任を提供いただいた @kerams さんに感謝します。

XML ドキュメントを再利用する

共有 APIの 備考を一度だけ設定するには、それらを shared.xml に記述してください:

<docs>
  <tracking>
    <remarks>An unrecognized tracking identifier has status Unknown.</remarks>
  </tracking>
</docs>

GenerateDocumentationFile を有効にすると、F# 11 は <include> を生成されるメンバー エントリに展開します:

/// <summary>Find the latest status of a shipment.</summary>
/// <include file="shared.xml" path="/docs/tracking/*"/>
let status trackingId =
    if trackingId = "SHP-1042" then "Dispatched" else "Unknown"

/// <summary>Find the latest statuses of several shipments.</summary>
/// <include file="shared.xml" path="/docs/tracking/*"/>
let statuses trackingIds =
    trackingIds |> List.map (fun id -> id, status id)

インクルード実装では、1 つのフラグメントから両方の説明が更新されます。 これとは別に、ツール リゾルバーは <inheritdoc/> の基本記述を公開しており、コンパイラはそのタグをドキュメントの利用者向けにそのまま残しています。 例と解決規則については、 XML ドキュメントを参照 してください。

@T-Gro が FSharp.Core で XML ドキュメントを共有してくれたことに感謝します。

最適化されていないビルドでインライン関数をデバッグする

インライン ヘルパーの引数を調べるには、最適化されていないビルドで let total にブレークポイントを設定し、addFee にステップ インします。 F# 11 では、次のビルドで呼び出し可能なメソッドが優先されるようになりました。

let inline addFee (fee: decimal) (amount: decimal) =
    let total = amount + fee
    total

let invoiceTotal = addFee 2m 40m
printfn "%M" invoiceTotal
// 42

最適化されたビルドはインライン化を保持します。 一部の構文は、引き続き拡張する必要があります。 これらの制限や --always-inline 制御については、インライン関数のデバッグを参照してください。

非同期とタスクの調整

F# ワークフローをタスク ベースの API に接続するために、FSharp.Core 11 では、キャンセル対応ブリッジ、有界バッチ、および結果変換が追加されます。

結果の収集だけでなく、未処理の I/O もバウンドします

大量のリードが処理されると、アプリケーションが処理すべき未処理の作業量を超えてしまう可能性があります。 タスク ベースの作業がいつ開始されるかを判断するには、コーディネーターには、すでに開始されているタスクではなく、ファクトリーが必要となります:

open System.IO
open System.Threading

let readFiles (paths: seq<string>) (ct: CancellationToken) =
    paths
    |> Seq.map (fun path ->
        fun token -> File.ReadAllTextAsync(path, token))
    |> Task.parallelLimit 4 ct

最大 4 つの読み取りが同時に実行されます。結果は入力順序を保持します。 エラーが発生した場合、提供されたトークンを用いて同じ階層のキャンセルを要求します。 これは同時実行数を制限するものであり、1 秒あたりの要求数を制限するものではありません。 シーケンシャルおよびユニット結果のバリアントについては、 非同期関数とタスク関数 を参照してください。

取り消しと基になる例外を境界を越えて保持する

ワークフローが外部作業を開始すると、そのトークンはその作業と共に移動する必要があります。 Async.StartTaskImmediate は、実行中のワークフローのトークンをタスクファクトリに渡し、完了を待ちます。

open System.IO

let tryReadFile path =
    async {
        try
            let! contents =
                Async.StartTaskImmediate(fun ct -> File.ReadAllTextAsync(path, ct))
            return Some contents
        with :? FileNotFoundException ->
            return None
    }

1 つのタスクの失敗は、基になる FileNotFoundException としてこのハンドラーに到達します。 既に作成されているタスクまたは値タスクの場合は、Async.Await を使用します。古い Async.AwaitTask は例外をラップする動作を保持します。

タスク ベースの呼び出し元の場合、 Task.startAsyncImmediate token workflow はリバース ブリッジを提供します。 最初の非同期中断まで、呼び出し元のスレッドで開始されます。

短い変換には、対応するヘルパー関数を使用します

完全な計算式を使わずに単一の結果を変換するには、Microsoft.FSharp.Control 内の対応するヘルパーを使用します。 たとえば、ファイルを読み込み、その長さを取得し、Error として通常の失敗を返す場合:

open System.IO
open System.Threading

let fileLength (path: string) (ct: CancellationToken) =
    File.ReadAllTextAsync(path, ct)
    |> Task.map String.length
    |> Task.catch

Report 1を含むファイルはOk 8を提供します。見つからないファイルは、Errorを含むFileNotFoundExceptionを返します。 キャンセルは引き続き適用されます。 Async と ValueTask には、対応する map、bind、エラー ヘルパーが用意されています。詳細は、非同期とタスク関数を参照してください。 分岐や複数の相互に依存する値には、コンピュテーション式を使用します。

ValueTask ヘルパーを使用するには、Core の netstandard2.1 または net10.0 ビルドと、1 回のみの使用が必要です。

@bartelink の async/task API への貢献に感謝します。

非同期エラー報告後の再送出

操作ログは、呼び出し元がキャッチする内容を変更したり、障害が発生した場所を非表示にしたりすることなく、情報を追加する必要があります。 計算式ハンドラーで、logger を await した後でも reraise () を使用できるようになりました。

open System
open System.IO
open System.Threading.Tasks

let readReport (logFailure: exn -> Task) path =
    task {
        try
            return! File.ReadAllTextAsync(path)
        with :? IOException as error ->
            do! logFailure error
            return reraise ()
    }

ログ記録が正常に完了すると、同じ例外と元のスローサイト情報が伝播されます。 ロガーの故障時には、元のものと交換可能です。 これにより、ランタイムでの非同期処理を伴わずに、非同期の監視に関する要求に対応できます。 詳細は、計算式からの再実行を参照してください。

サポートしていただいた @xperiandri さんに感謝します。

FSharp.Core は最新の .NET 上でビルドできます

古いターゲットを排除することなく最新の API を利用できるようにするため、FSharp.Core では net10.0 や netstandard2.0netstandard2.1 に加え、 も追加します。 NuGet は互換性のあるビルドを選択します。 ツールのパッケージが更新されたことで、コンパイル済みプロジェクトと同様に、F# Interactive でもタスク ベースの非同期破棄が可能になりました。 FSharp.Core ターゲット フレームワークを参照してください。

モダン Core ターゲティングと@T-Groについては、に感謝します。

ビルダー作成者向けのランタイム非同期処理

ビルダーの作者は、コンパイラが生成したステートマシンを使用する代わりに、ランタイムにマークされたメソッドの一時停止と再開を行わせることができます。 実験的なライブラリ定義のビルダーは、この仕組みを計算式として公開しています:

let readManifest (path: string) =
    runtimeTask {
        let! text = System.IO.File.ReadAllTextAsync path
        return text.Length
    }

FSharp.Core では、このサンプルを汎用的なビルダーとして提供していません。 通常の task と async コードは自動的にそれに切り替わるわけではなく、すでにコンパイル済みの通常のタスクを返す API を呼び出す側にとって、プレビューは本質的に必要ではありません。

ランタイム非同期対応について @majocha に感謝します。

Native AOT 対応のテキストと 2 次元配列

ネイティブ AOT をサポートするため、F# 11 では、一般的なテキスト操作や配列操作から、リフレクションに基づくフォーマット処理や動的割り当ての要件が削除されました。

冗長なフォーマット レイヤーを使用せずに値を出力し、文字列をビルドする

すでに文字列がある場合は、それを書き出すためだけに "%s" 形式を使用する必要はありません。 新しいコア関数printとstringは、F# のprintn変換によって値を受け取り、printnは改行を追加します。

let report (processed: int) (total: decimal) (elapsed: TimeSpan) : string =
    $"{processed} items, total {total:F2}, elapsed {elapsed.TotalMilliseconds:F0} ms"

printn (report 12 145.50m (TimeSpan.FromMilliseconds 250.0))
// 12 items, total 145.50, elapsed 250 ms

文字列補間では、より多くのケースで直接変換と String.Concat が使用されます。 {total:F2} のような .NET 形式のプレースホルダーは、インバリアント書式を使用し、値をボックス化します。一方、%A や精度指定付きの printf 形式では、引き続き printf の書式設定が必要になる場合があります。 ローカライズされた出力に使用する明示的なカルチャーを選択してください。

--reflectionfree を使用すると、レコードや共用体に対しても ToString 出力が生成されるようになります。 カルチャの例とサポートされているパスについては、 補間とネイティブ AOT に関するページを参照してください。

プリント関数を提供してくれた @bbatsov さん、補間機能を実装してくれた @charlesroddie さんに感謝します。

通常のゼロベースのグリッド操作を保持する

ゼロベースのグリッドの場合、動的なコード割り当ての処理を回避するためだけに、Array2D モジュールを置き換える必要はありません。 更新されたコア実装では、使い慣れた初期化と変換がサポートされます。

let grid = Array2D.init 3 4 (fun row column -> row * 4 + column)
let doubled = grid |> Array2D.map (fun value -> value * 2)
let snapshot = Array2D.copy doubled

printn $"{snapshot.GetLength(0)} x {snapshot.GetLength(1)}; last = {snapshot[2, 3]}"
// 3 x 4; last = 22

Array2D.create、init、および rebase は、コア ビルド全体で 0 から始まる割り当てパスを使用します。 境界保持のmap、mapi、およびcopyでは、net10.0 ビルドで新しい .NET の割り当て API を使用できます。.NET Standard ビルドでは、フォールバックが維持されます。 0 を基点としない配列は非推奨ではありませんが、ネイティブな割り当てに関する制限は引き続き残ります。

割り当てパスと残りの制限については、 2 次元配列とネイティブ AOT を参照してください。 アプリケーション全体の公開診断情報を確認してください。

Array2D の機能強化に対して @T-Gro に感謝します。

メモリの保持が少なく、作業の繰り返しが少なくなります

F# 11 では、コンパイラの繰り返し解析や、一部のアプリケーションによるメモリ割り当てが削減されます。 これらは、さまざまなワークロードに影響します。

プロジェクト間で参照先ライブラリを共有する

共有バイナリ依存関係の重複コピーを防ぐため、言語サービスは、条件を満たすインポート済みライブラリ グラフをプロジェクト間で共有できます。

PR で実装された保持メモリの実験では、10 個のプロジェクトからなる ReSharper.FSharp ソリューションのメモリ使用量が、共有機能を有効にしたことで 1,547.2 MB から 1,002.2 MB に減少しました。 これはそのワークロードにおけるオン/オフの測定値であり、F# 全般における 10 対 11 の削減率を示すわけではありません。 共有バイナリ参照ではなくプロジェクト参照によって支配されるソリューションは、はるかに小さな改善しか見られないことがあります。

メタデータの読み取りやインライン特化も、別の指標である一時的なメモリ割り当てを削減します。 スコープとコントロールについては、ツーリングのパフォーマンスを参照してください。

ライブラリのインポート情報を共有していただいた @auduchinok さんに感謝します。

デフォルトで、独立した作業を並行してコンパイルする

並列コンパイルがデフォルトで有効になり、確定的な出力とソース順のルールが維持されるようになりました。 オーバーロード キャッシュとガード付きパターンの改善により、その他の重複作業を回避できます。 Visual Studio/FCS では、変更されていないドキュメントの分析やバウンド同時実行チェックも削減されます。詳細はツールのパフォーマンスを参照してください。

コールバックと空の結果オブジェクトの割り当てによるオーバーヘッドを回避する

選択した List 関数と Array 関数で、コールバックをインライン化できるようになりました。 独自のインライン ヘルパーの場合、OptimizeClosureIfNotInlined は不透明なカリー化されたコールバックを一度だけ適応させます:

let inline foldItems
    ([<InlineIfLambda; OptimizeClosureIfNotInlined>] folder)
    state
    (items: 'T[]) =
    let mutable total = state
    for item in items do
        total <- folder total item
    total

その他の割り当てはそのままにしておくことができます。 要件については、カリー化されたコールバックの最適化を参照してください。

作業が成功した典型的な例の一つとして、結果が空である場合もあります。 FSharpLint の動機付けワークロードでは、警告を検出しないルールが繰り返し組み合わされていました。 Core で、より多くの操作において共有された空の配列が再利用されるようになりました。

let checkTitle (title: string) =
    if String.IsNullOrWhiteSpace title then [|"A title is required."|]
    else Array.empty

let warnings = ["Introduction"; "Installation"] |> List.toArray |> Array.collect checkTitle
let sharedEmpty = obj.ReferenceEquals(warnings, Array.empty<string>)
// true: no new empty result array

この変更により、パイプライン内のすべての割り当てではなく、冗長な空配列オブジェクトが削除されます。 個別の空の結果が、それぞれ異なる参照 ID を持つことを期待しないでください。

インラインのコレクション コールバックと共有の空配列についてご協力いただいた、@T-Gro さんに感謝します。

より正確な API 呼び出しと日常で役立つ便利機能

生成されたパラメーターの順序が変更される可能性があるときに名前を要求する

生成された API を、パラメーター順の無通知の変更から保護するため、作成者は名前付き引数の使用を必須にすることができます:

open System.Diagnostics.CodeAnalysis

type Query =
    [<RequireNamedArguments>]
    static member Execute(numerator: decimal, denominator: decimal) =
        numerator / denominator

let ratio = Query.Execute(numerator = 3m, denominator = 4m)
// 0.75M; Query.Execute(3m, 4m) is rejected.

宣言の順序を変更しても、名前付き呼び出しの結果 0.75M は保持されますが、位置ベースの呼び出しは拒否されます。 生成された API ユース ケースの場合、プロバイダーは注釈を出力する必要があります。

既にラップされているジェネリック引数を認識する

既存のタスクをプレーンな結果値としてラップしないように、新しい最後の手段のオーバーロード ルールでは、ベア Task<'T>よりも 'T が優先されます。

open System.Threading.Tasks

let pending = Task.FromResult 42
let wrapped = ValueTask<_>(pending)
let answer: int = wrapped.Result
// ValueTask<int>, not ValueTask<Task<int>>

結果はValueTask<Task<int>>であり、ValueTask<int>ではありません。 ルールの制限については、「 オーバーロードの選択」 を参照してください。

古いエントリ ポイントを削除せずに新しいオーバーロードを優先する

ライブラリは、呼び出し元のソース位置を含むオーバーロードを追加するときに、既存のバイナリの古い診断メソッドを保持する場合があります。 OverloadResolutionPriorityAttribute は、新しくコンパイルされた呼び出し元に対して、その設定を明示的に指定します:

open System.Runtime.CompilerServices

type Check =
    static member That(condition: bool) =
        if condition then "OK" else "Check failed."

    [<OverloadResolutionPriority(1)>]
    static member That(condition: bool, [<CallerLineNumber>] ?line: int) =
        if condition then "OK" else $"Check failed at line {defaultArg line 0}."

let stock = 0
let diagnostic = Check.That(stock > 0)
// The diagnostic includes the caller's source line.

呼び出しを変更しなくても、行情報対応のオーバーロードが選択されます。 スコープと互換性の規則については、「 オーバーロードの選択」 を参照してください。

.NET の条件付きnull 許容性の機能を活用する

ファイルパスが null ではない場合、Path API の戻り値が nullable として扱われている場合でも、その API 自身の契約によって否定されているはずの null チェックを強制されるべきではありません。F# 11 は、既存の .NET の NotNullIfNotNull という保証を利用します。つまり、名前付きの入力値が null でなければ、戻り値も null ではないという保証です。

open System.IO

let fileName: string = Path.GetFileName("reports/annual.csv")
let extension: string = Path.GetExtension(fileName)
printn (extension.ToUpperInvariant())
// .CSV

let fileNameOf (path: string | null) : string | null =
    Path.GetFileName path

<Nullable>enable</Nullable> を有効にします。 Null 許容入力には、引き続き null 許容の処理が必要です。 条件付き戻りコントラクトを参照してください。 制約のない C# T? API については、別の Unchecked.withNull ヘルパーを使用してください。

条件付き null 許容のサポートを提供していただいた、@kerams さんに感謝します。

言語に関する小規模な改善

レコード型を .NET のコンストラクター構文で呼び出すには、F# 11.2 の レコード コンストラクター を使用します:

type Person = { Name: string; Age: int }
let person = Person(Name = "Ada", Age = 36)

名前付き引数は、フィールドの順序への依存を回避します。 この機能については @charlesroddie に感謝します。

条件付きソースの場合、#elif は #if グループのネストを回避します:

#if EU_WAREHOUSE
let dispatchTimeZone = "Europe/Paris"
#elif US_WAREHOUSE
let dispatchTimeZone = "America/New_York"
#else
let dispatchTimeZone = "UTC"
#endif

System.Console.WriteLine(dispatchTimeZone)

最初に一致するブランチが優先されます。 サンプル プロジェクトは EU_WAREHOUSE を定義し、Europe/Paris を出力します。どちらのシンボルも定義されていない場合、出力は UTC になります。

関連するツールと相互運用のケース:

• 対話型ツールチェーンを識別するには、 #versionを使用します。
• 外部ホストとソースを共有するために、F# では #: 行のホスト ディレクティブを受け付けますが、これらはパッケージやビルドの指示として解釈されることはありません。
• 冗長なインターフェイス宣言を回避するには、 派生インターフェイスの既定の実装を使用します。
• 通常のクロージャ内で継承された状態を読み取るには、保護されたベース フィールドに対する新しい機能を使用します。

アップグレードする前に

アップグレードの際は、以下の重要な変更点に留意してください: