CS2001～

C#コンパイラエラーCS8162の原因と解決策について解説

2025-03-29更新日: 2025-03-29

C#のコンパイラエラーCS8162は、読み取り専用フィールドのメンバーをrefで返そうとする際に発生します。

たとえば、構造体のメンバーに対して書き込み可能な参照を返すとこのエラーが出ます。

対応策としては、フィールドの値を直接返すように変更するとエラーが解消されます。

目次から探す

エラー原因の詳細
- 読み取り専用フィールドの性質
- 参照返し使用時の問題点
サンプルコードによる分析
- 発生例の確認
- 修正例の検証
解決方法の検討
- 対応策の選択肢
- 実装時の注意点
まとめ

エラー原因の詳細

読み取り専用フィールドの性質

readonlyフィールドの制約と挙動

C#では、readonlyキーワードが付与されたフィールドは、インスタンスの初期化後に変更できないことが定義されています。

これにより、オブジェクトの状態が不意に変更されるリスクを減らし、安全性が高まります。

例えば、コンストラクタで一度設定された後は、そのフィールドの値が保証されるため、プログラムの動作が一貫して安定します。

書き込み可能な参照の禁止理由

もしreadonlyフィールドのデータに対して書き込み可能な参照を返すことができれば、フィールドが保持する不変性が崩れる恐れがあります。

実際、読み取り専用のフィールドを外部に書き込み可能な形で公開すると、本来の保護意図が損なわれ、予期せぬ副作用やバグを引き起こす可能性があります。

そのため、コンパイラは書き込み可能な参照の返却を禁止し、エラーCS8162を発生させる設計になっています。

参照返し使用時の問題点

エラーCS8162発生のメカニズム

readonlyフィールドに対して、書き込み可能な参照refを返すような実装を行うと、フィールド内のデータが外部から変更されるリスクが生じるため、C#コンパイラはエラーCS8162を発生させます。

これは、コンパイラがフィールドの設計意図である不変性(immutability)を尊重し、安全なコードを書くための保護機能として働いています。

サンプルコードによる分析

発生例の確認

構造体内メンバーの利用パターン

下記のサンプルコードでは、構造体S1のメンバーxがreadonlyフィールドi2の一部として宣言されています。

refを使ってこのメンバーを返そうとすると、コンパイル時にエラーCS8162が発生する仕組みを確認できます。

using System;
public class Test {
    // 構造体S1の宣言。メンバーxはchar型です。
    public struct S1 {
        public char x;
    }
    // readonly修飾されたフィールド
    public readonly S1 i2;
    // readonlyフィールドのメンバーをref返ししようとしてエラーが発生する例
    ref char Test1() {
        return ref i2.x;
    }
    public static void Main() {
        // インスタンス生成(コンストラクタがないためメンバーは既定値)
        Test instance = new Test();
        // エラーを確認するためにTest1の呼び出しはしていません
    }
}

error CS8162: Cannot return a writable ref to 'i2.x' because it is a readonly field.

エラー発生箇所の特定

上記のコードでは、メソッドTest1内でi2.xをrefで返そうとしている部分が問題となっています。

具体的には、readonlyフィールドの一部であるxに書き込み可能な参照を返すことが許されず、コンパイラがエラーを報告しています。

これにより、メンバーへの外部からの不正な書き込みが防止される設計となっていることが確認できます。

修正例の検証

値渡しへのリファクタリング方法

エラーCS8162を回避するためには、refによる参照返しをやめ、直接値を返すようにリファクタリングする方法が有効です。

以下のサンプルコードは、Test1メソッドから返す型をcharに変更し、値渡しで返すことでエラーを解消しています。

なお、Main関数内でフィールドの初期化を行い、動作確認を行えるようにしています。

using System;
public class Test {
    public struct S1 {
        public char x;
    }
    public readonly S1 i2;
    // コンストラクタでi2を初期化。xに'A'を設定。
    public Test() {
        i2 = new S1 { x = 'A' };
    }
    // 値渡しで返すように修正
    char Test1() {
        return i2.x;
    }
    public static void Main() {
        Test instance = new Test();
        char result = instance.Test1();
        Console.WriteLine(result);  // 'A'が出力されます
    }
}

修正後の動作比較

リファクタリング後は、refではなく値の返却となるため、コンパイラエラーCS8162は発生しません。

実行結果も意図した通りの出力が得られ、読み取り専用フィールドの不変性が保たれたまま正しく動作することが確認されます。

比較すると、元の例ではコンパイルエラーが発生していたのに対し、修正例では正常にコンパイル・実行できる点が大きな違いです。

解決方法の検討

対応策の選択肢

コードリファクタリングの手法

エラーCS8162の問題に対しては、基本的な解決策として参照返しを使用せず、値渡しで返す方法が推奨されます。

コードのリファクタリングとして下記の手法が考えられます。

メソッドシグネチャからrefを削除し、単に値を返すように変更する
もし大きなデータ構造の場合、コピーコストが懸念されるが、セーフティを優先する設計に変更する

このような手法により、readonlyフィールドが持つ安全性を維持しつつ、機能要件も満たす設計が実現できます。

既存実装との整合性確認

既存実装の中でrefを使った参照返しが必要不可欠なケースもありますが、readonlyなフィールドの場合は整合性が保たれなくなるリスクがあります。

既存のコードを見直し、値渡しで問題がないか、あるいは別の設計変更が必要かを検討することが重要です。

全体の設計方針に合わせたリファクタリングが求められます。

実装時の注意点

参照返しと値渡しの違いの留意点

参照返し(ref)は、元のデータへの直接アクセスを可能にするため、変更の際のパフォーマンス面で利点があります。

しかし、その分、データの不変性が求められる場合には注意が必要です。

readonlyフィールドの場合、値渡しで返すことにより、以下の点に留意する必要があります。

書き込み不可の保証が保たれるため、意図しないデータの変更を防げる
コピーに伴うパフォーマンスの低下がある可能性があるが、安全性を優先する選択が重要

このような違いを理解し、プログラムの要件に合わせた実装選択を行ってください。

まとめ

本記事では、readonlyフィールドの性質と、そのフィールドから書き込み可能な参照を返そうとする際に発生するエラーCS8162の原因について解説します。

サンプルコードを用いて、構造体内メンバーの利用パターンやエラー発生箇所を明らかにし、値渡しへリファクタリングする手法を説明しました。

これにより、フィールドの不変性を保ちながら正しく動作するコードの実装方法が理解できる内容です。