物事を不変にするための言語構造があればいいと思いませんか？ そうすれば、これらの魔法のインターフェースを持つ必要はありません。

@whoisjどの言語？ CLRには数十個あります。

潜在的な言語機能としても、メタデータ表現が必要になります。 この場合、マーカーインターフェイス（または動作インターフェイス）は他のインターフェイスと同じくらい優れています。 新しいメタデータエントリを介してコレクションタイプの不変性を伝えようとすることは、CLRが任意のクラスが内部でどのように機能するかについて仮定を行うべきではないため、適切ではないようです（CLRにはコレクションクラスの概念がまったくありません。配列）。

@whoisjこれは少なくとも将来のC＃バージョンの1つで考慮されていると思います。 ただし、その決定は、すべてのコレクションにわたる対称インターフェースの必要性に影響を与えません。 さらに、コードの品質とパフォーマンスの両方を重視するゲームなど、可変アイテムの読み取り専用リストが役立つシナリオを想像することもできます。

また、不変のコレクションはすでに利用可能です。

https://msdn.microsoft.com/en-us/library/system.collections.immutable（v = vs.111）.aspx

完全に不変のコレクションを実現するには、 immutable Tを定義し、それを使用してImmutable...<T>コレクションを宣言する方法が必要です。

@HaloFour ：smirk：の前にこの道をthis ）」。

@dsaf絶対に！ 別の問題では、書き込み可能な要素の読み取り専用コレクションの使用を可能にするために、読み取り専用の書き込み可能なアンチタームを用意することを提案しました。 readonly Bag<writable Element>の線に沿った何か。

&でマークされた参照は、コンパイラーによって不変として扱われることを提案しました。 私はまだコンパイル時のチェックだけが必要であり、実行時の保証ではなくロジックのコンパイル時の検証を主に求めているため、CLR自体によって強制される必要があると感じています。 これは、開発者が不変であることを望んでいたすべての参照をカバーしますが、呼び出しごとに行われます。

@whoisjおそらく、それはかなり接線的であり、dsafが今日の午後に分岐/ PRできるものからのこの要求を、3つの異なるチーム間の努力を伴うものに変えます。

また、これをコンパイラの問題として扱っています。 この時点では、（JITコンパイラ以外に）コンパイラは関与しておらず、「不適切な」コードの実行を防止できるのは検証者だけです。 不変性の既存のランタイムメカニズムであるinitonlyフィールドでさえ、検証がスキップされた場合（またはリフレクションを介して）、簡単に無効になる可能性があります。

私は、C＃言語とコンパイラが「純粋な」メソッドをより適切にサポートできれば素晴らしいと思います。 属性PureAttributeすでに存在しますが、散発的に使用されており、実際には言語サポートはありません。 また、C＃がコンパイラエラー（pureはpureのみを呼び出すことができるなど）によってサポートしていたとしても、別の言語を使用することで簡単に無効にできます。 ただし、これらのメソッドは、ILにコンパイルされると基本的にすべての賭けが無効になり、既存のアセンブリの実行方法を曲げることができないため、自分自身をアナウンスして強制する必要があります。

@HaloFourフェア。

「純粋な」または「定数」の参照をサポートする一般的な方法がないと仮定すると、提案されたものが最良の代替手段であると思います。

今すぐ必要な場合は、私のCommonsライブラリ（Commons.Collections https://github.com/yanggujun/commonsfornet/tree/master/src/Commons.Collections/Set）で読み取り専用セットがサポートされています。 これが広告と思われる場合、管理者はこの投稿を削除してください...私の提案はいくつかのオープンソースの実装を探し回ることです。

@yanggujun提案をありがとう、それは素晴らしいライブラリのようですが、余分な依存関係を避けるために私は自分自身をロール

私の提案は、いくつかのオープンソースの実装を探し回ることです。

これは回避策であり、IReadOnlySetのような基本的なインターフェイスは実際には.NETFramework自体の一部である必要があります。

これには「APIレビューの準備ができている」ためのスペックレットが必要ですか？

そして、私たちがそれに取り組んでいる間、それを「ReadOnly」とは異なる名前にすることを検討してください（興味深い投稿を参照してください：http：//stackoverflow.com/questions/15262981/why-does-listt-implement-ireadonlylistt-in-net-4- 5）
「読みやすい」は問題ないようです。

@GiottoVerducciいいえ。不完全な場合でも、一貫した命名パターンを維持したいと思います。 ただし、既存のインターフェースの名前を変更するために、別の問題を自由に提起することができます。

提案されたAPI設計：

public interface IReadOnlySet<T> : IReadOnlyCollection<T> {    
    bool Contains(T item);
    bool IsSubsetOf(IEnumerable<T> other);
    bool IsSupersetOf(IEnumerable<T> other);
    bool IsProperSupersetOf(IEnumerable<T> other);
    bool IsProperSubsetOf(IEnumerable<T> other);
    bool Overlaps(IEnumerable<T> other);
    bool SetEquals(IEnumerable<T> other);
}

これはISet<> APIに基づいています（明らかにミューテーションメソッドを除く）。

Comparerがこれに当てはまらないのは残念ですが、 ISet<>もIReadOnlyDictionary<>比較対象を公開していないため、今すぐ修正するには遅すぎます。

    bool Contains(T item);

ICollection<T>はContains(T item)があるので、これIReadOnlyCollection<T>代わりに

不変のコレクションパッケージは、まだベータ版である間、nugetからリストから外されました。
これはかなり一般的なユースケースであり、標準のライブラリで処理する必要があると思います。

タグが示すように、ここでAPIに対して行うべき作業は他にもありますか？ それが役に立ち、誰かが何が必要かを指摘することができれば、私はこれに少し時間を費やしてうれしいです。

提案されたAPI @ ashmindは素晴らしく見えます。

ISet<T>にIReadOnlySet<T>を拡張させることはできますか？ これは起こりませんIList<T> / IReadOnlyList<T> ？

そうでない場合は、考慮すべき他の変更は、 HashSet<T> 、 SortedSet<T> 、およびそれらを含むcorefxのすべてのISet<T>実装のインターフェイスリストにIReadOnlySet<T>を追加することだと思います。 System.Collections.Immutable不変の対応物。

@GiottoVerducciに同意するIReadOnlySet<T>ような名前を使用しても、コントラクト機能は宣言されません。コントラクトの制限が宣言されます。 次に、それらの制限と矛盾する別の契約と組み合わせて同じ契約を使用することは混乱を招きます。 契約名は、実装者がサポートするものに関する肯定的な主張を説明する必要があると思います。 確かに、 IReadableSet<T>ような名前は素晴らしいものではありませんが、少なくとも実装者が何をするかをよりよく説明しています。

@HaloFour原則的に同意しますが、 IReadOnlyList<T>でも同じ状況になりました。 一貫性を維持することは、ここでの精度の向上よりも重要です、IMHO。

@drewnoakes

私は理解しています、そして一貫性が重要です。 しかし、それはISet<T>がIReadOnlySet<T>拡張すべきではない理由にも答えると思います。

一貫性を維持することは、ここでの精度の向上よりも重要です、IMHO。

しかし、それはISet<T>がIReadOnlySet<T>拡張すべきではない理由にも答えると思います。

私はあなたが要点を逃していると思います。 すなわち、その理由ですIList<T> 、 ICollection<T> 、 IDictionary<TKey, TValue> 、他にすべきであるISet<T> 、また、読取り専用ビューインタフェースを実装するために固定されます。 そうしないと、BCLの直感的でない設計を回避するときに、誰もががあります。

@binki

私は同意しません。 それについて私が気に入らないのは、読み取り専用の動作を規定するコントラクトが、読み取り専用の動作を規定するコントラクトによって拡張されることです。 名前が間違っていて、構成が間違っています。 しかし、ここにあります。 両方を変更するために投票したいのですが、それがテーブルにあるとは思えません。

@HaloFour

何かへのインターフェースを取得するとき、それは何かへの_ビュー_です。 ビュー自体は読み取り専用です。 タイプセーフなコードを記述し、アップキャストを回避しないと仮定すると、読み取り専用のコードを受け取った場合、それはすべての目的と目的において、読み取り専用です。 これは、データが変更されないことを保証するものではありません。 これは、ファイルを読み取り専用で開くのと同じです。 読み取り専用で開かれたファイルは、別のプロセスによって変更できます。 または、管理者がデータの読み取り/書き込みビューを持ち、自分の下からデータを変更できるWebサイト上のページへの読み取り専用アクセスのように。

ここで読み取り専用が間違った用語と見なされる理由がわかりません。 読み取り専用は、不変を意味しません。 必要に応じて、nugetパッケージ全体/さまざまなAPI（追加/削除によって新しいオブジェクトが生成され、現在のインスタンスが変更されないことが保証されているため、不変である）があります。

私は似たようなことを考えていました。 .NETの「読み取り専用」は、フィールドに対してもかなり弱い保証です。 やり直しを考えると、これはすべてもっと理にかなっていると確信しています。 今のところ、実用的である価値があります。

したがって、一般に、メソッドがIReadOnlySomething<T>を受け入れる場合、一般に、メソッドはそれを変更しないと想定できます。 受信メソッドが参照をアップキャストしないという保証はありません。また、アクセス時にインターフェイスの実装が内部的に変更されないという保証もありません。

C ++では、 const_castはconstの保証も弱めます。これは残念ですが（特に最近ではmutable修飾子を使用）、実際にはその有用性が損なわれることはありません。 constは機能としてです。 あなたは自分が何を扱っているのかを知る必要があります。

@binkiは良い区別をします。 名前の_Immutable_は、関係するすべての人の長期にわたる安定性のハード保証を意味します。

IList<T>がIReadOnlyList<T>拡張しない理由について信頼できる情報源を持っている人はいますか？

@binki

インターフェースはビューではなく、コントラクトです。 その契約は、実装者の能力を宣言します。 実装者が実際にこれらの機能を実装していない場合は、契約違反と見なします。 そのList<T>クラスは、それが「is-a」 IReadOnlyList<T>であると主張していますが、そうではありません。 それはその能力を欠いています。

このテーマについては、複数の考え方があります。 私は明らかに、インターフェースの継承がタイプ間の「is-a」関係に厳密に従う学校に属しています。 私は確かにインターフェースを使った構成へのよりきめ細かいアプローチをサポートしており、 List<T>とその親族は、3〜4個の追加インターフェース（読み取り、書き込み、追加など）を実装することでおそらく恩恵を受けると思います。インターフェイスの名前は、タイプが実行できないことではなく、実行できることを説明する必要があります。 ネガティブケイパビリティアサーションは、契約にはあまり意味がありません。

@drewnoakes

今のところ、実用的である価値があります。

同意します。 私たちは今いるところです。 IList<T>を変更してIReadOnlyList<T>を拡張する場合、 ISet<T>を変更してIReadOnlySet<T>などを拡張することは理にかなっています。

IReadableX<T> 、 IWritableX<T>などのインターフェイスをIReadOnlyX<T>と共存させるには冗長すぎますか？

IList<T>がIReadOnlyList<T>拡張しない理由について信頼できる情報源を持っている人はいますか？

どうやら、古い.netフレームワークに対してコンパイルされたアセンブリをロードするときのABIを破る変更になるでしょう。 IList<T>を持たないBCLに対してIList<T>実装するクラスをコンパイルした場合、インターフェイスを実装するときに、ソースコードが暗黙的なインターフェイス実装に依存している場合、ほとんどのコンパイラは明示的なインターフェイス実装を自動的に生成するためです。 IReadOnlyList<T>実装すると、コンパイラは明示的なIReadOnlyList<T>実装を自動的に作成しません。 私がこの権利を読んでいる場合： http ：

@HaloFour List<>とHashSet<>はICollection<>とIReadOnlyCollection<>実装しているので、 IReadOnlyがアクセスを参照し、容量。 これに基づいて、 IAnything IReadOnlyAnythingを拡張させることは完全に理にかなっています。 IReadableがIReadOnlyよりも優れていることに同意しますが、この時点で、誰もがIReadOnlyから_mean_ IReadableを理解し、そのように使用しています。 実際、私は自分のコードベースで意図的にそれを永続させています。なぜなら、物事について2つの考え方を持つことは、私の意見では何よりも認知的負荷が大きいからです。

名前にこだわっていますが、その背後にある概念は十分に強力なので、具体的なクラスの場合と同じように、すべてのインターフェイスでIReadOnlyを拡張できることを心から願っています。

@ashmindどの方法も比較対象をとらないのは完璧だと思います。 セットや辞書では、比較子はオブジェクト全体の構造を決定するため、簡単に交換できるものではありません。 また、比較子をCaseInsensitiveStringCollectionまたは特定の比較を意味するコレクションに渡すことは意味がありません。

（すでに利用可能な拡張メソッドよりも効率的にContains(T, IEqualityComparer<T>)実装する奇妙なコレクションの場合、それはおそらく1回限りのクラスメソッドです。 Contains(T, IEqualityComparer<T>)が一般的であるとは想像しがたいです。専用のインターフェースにたどり着くには十分ですが、それでもそれが起こるのを止めるものは何もありません。）

@ jnm2

どの方法も比較対象をとらないのは完璧だと思います。

明確にするために、私はそれが比較対象を公開するべきであり、比較対象を取得するべきではないと言いたかったのです。 すべてのセットまたはディクショナリには何らかの等式アルゴリズムが必要であるため、これはインターフェイスで公開されている可能性があります。 しかし、今のところ、そのユースケースを覚えていません。外部から提供されたものと同じ比較子を使用してセットを作成するようなものです。

この議論は多くの興味深い点をもたらしますが、このスレッドを開始した単純で明白な提案からはほど遠いようです。 そして、私はこの問題が解決されることを本当に望んでいるので、それは落胆しています。

OPが述べたように、IReadOnlySetなしでIReadOnlyListが追加されたときにコレクションタイプ間のパリティを維持できないことは残念であり、多くの人が回避策として独自のバージョンのIReadOnlySetインターフェイスを実装しています（私自身のチームにも同様の回避策があります）。 corefxクラスはそれらを実装できないため、これらの回避策インターフェイスは理想的ではありません。 これがフレームワークでこれを提供する主な理由です。HashSetがある場合は、すでに持っているオブジェクトをコピーしたりラップしたりせずに、IReadOnlySetとして使用できるようにしたいと考えています。 パフォーマンスのためには、少なくともこれが望ましいことがよくあります。

インターフェイスの名前は明らかにIReadOnlySetである必要があります。 一貫性は、IReadOnlyXXX名に関する懸念よりも優先されます。 その船は出航した。

既存のインターフェース（IReadOnlyCollection）は変更できません。 .NETのバックコンパット要件では、そのような変更は許可されていません。 比較者が既存のIReadOnlyXXXインターフェースで公開されていないのは残念ですが（私もこれに遭遇しました）、船は再び出航しました。

実用的な観点から残っていると思われる唯一の質問は、インターフェイスのこれら2つの潜在的な定義の間です。

以前に@ashmindによって提案され

public interface IReadOnlySet<T> : IReadOnlyCollection<T> {    
    bool Contains(T item);
    bool IsSubsetOf(IEnumerable<T> other);
    bool IsSupersetOf(IEnumerable<T> other);
    bool IsProperSupersetOf(IEnumerable<T> other);
    bool IsProperSubsetOf(IEnumerable<T> other);
    bool Overlaps(IEnumerable<T> other);
    bool SetEquals(IEnumerable<T> other);
}

最小限の提案：

public interface IReadOnlySet<T> : IReadOnlyCollection<T> {    
    bool Contains(T item);
}

個人的には、他の方法を導き出すことができるので、この最小限の提案を好みます。 理想的には、IReadOnlySetインターフェイスを介した拡張メソッドとしてそれらの標準実装があるため、IReadOnlySetの実装者はそれらを提供する必要はありません。 また、この最小限の提案は、他の最小限のIReadOnlyXXXインターフェイスとより一致していると感じています。

@ aaron-meyers私が抱く唯一の懸念は、 IsSubsetOfとその友人がContainsから_効率的な方法で派生できないことです。 たとえば、2つのハッシュテーブルの場合、 Containsに依存すると、実装はハッシュマッチングではなくネストされたループを使用するようになります。

おそらく新しいインターフェース、 IComparableSet<T>にはset操作が含まれている可能性があります。

いくつかのセット操作のために、 IEnumerable<T>にすでに拡張メソッドがあります。

@ jnm2 HashSetで実装には、 Containsと他のコレクション（IReadOnlySetがIReadOnlyCollectionを継承することで取得するコレクション）の列挙のみが必要です。 ただし、他のセットが同じ比較子を使用していることを知っている必要があります。 おそらく、これらの操作を拡張メソッドで効率的に実装できるように、ComparerプロパティをIReadOnlySetに追加する価値があります。 IReadOnlyDictionaryがKeyComparerも公開しないのは残念ですが、完全に一貫しているわけではありませんが、これをIReadOnlySetに追加する価値があるかもしれません。 ここで説明するように、そもそもIReadOnlyDictionaryに含めるべきだったのには十分な理由があります。

変更された提案は次のようになります。

public interface IReadOnlySet<T> : IReadOnlyCollection<T> {    
    IEqualityComparer<T> Comparer { get; }
    bool Contains(T item);
}

あるいは、Comparerを別のインターフェイスに配置し、set操作の拡張メソッドの実装では、両方のオブジェクトがインターフェイスを実装し、同じComparerを使用している場合にのみ、効率的なルートを使用します。 同じアプローチをIReadOnlyDictionaryに適用できます（実際、おそらく同じインターフェイスを使用しているだけです）。 ISetComparableのようなもの。 または、 @ drewnoakesから描画すると、IComparableSetが存在する可能性がありますただし、集合演算子を定義する代わりに、比較子を定義するだけです。

public interface IComparableSet<T> : IReadOnlySet<T> {    
    IEqualityComparer<T> Comparer { get; }
}

この場合、IReadOnlySetはContainsの定義に戻ります。

public interface IReadOnlySet<T> : IReadOnlyCollection<T> {    
    bool Contains(T item);
}

public interface IReadOnlySet<T> : IReadOnlyCollection<T> {    
    bool Contains(T item);
}
public interface IReadOnlySetEx<T> : IReadOnlySet<T> {    
    bool IsSubsetOf(IEnumerable<T> other);
    bool IsSupersetOf(IEnumerable<T> other);
    bool IsProperSupersetOf(IEnumerable<T> other);
    bool IsProperSubsetOf(IEnumerable<T> other);
    bool Overlaps(IEnumerable<T> other);
    bool SetEquals(IEnumerable<T> other);
    IEqualityComparer<T> Comparer { get; }
}
public class HashSet<T>: IReadOnlySetEx<T>, ISet<T>
{
   // Improved implementation here.
}

public static class CollectionExtensiosn
{
    public static IEqualityComparer<T> GetComparer<T>(this IReadOnlySet<T> @set)
    {
           var setEx = <strong i="5">@set</strong> as IReadOnlySetEx<T>;
           if (setEx == null)
           {
                throw new ArgumentException("set should implement IReadOnlySetEx<T> for this method.")
           }
           return setEx.Comparer;
    }

    public static bool IsSubsetOf<T>(this IReadOnlySet<T> <strong i="6">@set</strong>, IEnumerable<T> other)
    {
         var setEx = <strong i="7">@set</strong> as IReadOnlySetEx<T>;
         if (setEx != null)
         {
              return setEx.IsSubsetOf(other);
         }
         // Non optimal implementation here.
    }

    // The same approach for dictionary.
    public static IEqualityComparer<T> GetKeyComparer<T>(this IReadOnlyDictionary<T> dictionary)
    {
           var dictionaryEx = set as IReadOnlyDictionaryEx<T>;
           if (dictionaryEx == null)
           {
                throw new ArgumentException("dictionary should implement IReadDictionaryEx<T> for this method.")
           }
           return dictionaryEx.KeyComparer;
    }

}

このアプローチを使用できます。
使用法は次のようになります。

IReadOnlySet<string> mySet = new HashSet<string>();
bool test = mySet.IsSubsetOf(new []{"some", "strings", "set"}); // Extension method
var = mySet.GetComparer(); // Extension method

多くの要件が満たされ、IReadOnlySetミニマルです。 しかし、GetComparerはプロパティではなくメソッドになりました。 しかし、それは良いトレードオフです。

    /// <summary>
    /// Readable set abstracton. Allows fast contains method, also shows that collection items are unique by some criteria.
    /// </summary>
    /// <remarks>
    /// Proposal for this abstraction is discussed here https://github.com/dotnet/corefx/issues/1973.
    /// </remarks>
    /// <typeparam name="T">The type of elements in the set.</typeparam>
    public interface IReadOnlySet<out T> : IReadOnlyCollection<T>
    {
        /// <summary>
        /// Determines whether a <see cref="T:System.Collections.Generic.HashSet`1"/> object contains the specified
        /// element.
        /// </summary>
        /// <typeparam name="TItem">The type of the provided item. This trick allows to save contravariance and save from boxing.</typeparam>
        /// <returns>
        /// true if the <see cref="T:System.Collections.Generic.HashSet`1"/> object contains the specified element;
        /// otherwise, false.
        /// </returns>
        /// <param name="item">The element to locate in the <see cref="T:System.Collections.Generic.HashSet`1"/> object.</param>
        bool Contains<TItem>(TItem item);
    }

namespace System.Collections.Generic
{
    /// <summary>
    /// Provides the base interface for the abstraction of sets. <br/>
    /// This is full-featured readonly interface but without contravariance. See contravariant version
    /// <see cref="IReadOnlySet{T}"/>.
    /// </summary>
    /// <typeparam name="T">The type of elements in the set.</typeparam>
    public interface IReadableSet<T> : IReadOnlySet<T>
    {
        /// <summary>
        /// Gets the <see cref="Generic.IEqualityComparer{T}"/> object that is used to determine equality for the values
        /// in the set.
        /// </summary>
        /// <returns>
        /// The <see cref="Generic.IEqualityComparer{T}"/> object that is used to determine equality for the values in the
        /// set.
        /// </returns>
        IEqualityComparer<T> Comparer { get; }

        /// <summary>
        /// Determines whether a <see cref="T:System.Collections.Generic.HashSet`1"/> object contains the specified
        /// element.
        /// </summary>
        /// <returns>
        /// true if the <see cref="T:System.Collections.Generic.HashSet`1"/> object contains the specified element;
        /// otherwise, false.
        /// </returns>
        /// <param name="item">The element to locate in the <see cref="T:System.Collections.Generic.HashSet`1"/> object.</param>
        bool Contains(T item);

        /// <summary>
        /// Determines whether the current set is a proper (strict) subset of a specified collection.
        /// </summary>
        /// <returns><see langword="true"/> if the current set is a proper subset of <paramref name="other"/>; otherwise, false.</returns>
        /// <param name="other">The collection to compare to the current set.</param>
        /// <exception cref="ArgumentNullException">
        /// <paramref name="other"/> is null.
        /// </exception>
        bool IsProperSubsetOf(IEnumerable<T> other);

        /// <summary>Determines whether the current set is a proper (strict) superset of a specified collection.</summary>
        /// <returns>true if the current set is a proper superset of <paramref name="other"/>; otherwise, false.</returns>
        /// <param name="other">The collection to compare to the current set. </param>
        /// <exception cref="ArgumentNullException">
        /// <paramref name="other"/> is null.
        /// </exception>
        bool IsProperSupersetOf(IEnumerable<T> other);

        /// <summary>Determines whether a set is a subset of a specified collection.</summary>
        /// <returns>true if the current set is a subset of <paramref name="other"/>; otherwise, false.</returns>
        /// <param name="other">The collection to compare to the current set.</param>
        /// <exception cref="ArgumentNullException">
        /// <paramref name="other"/> is null.
        /// </exception>
        bool IsSubsetOf(IEnumerable<T> other);

        /// <summary>Determines whether the current set is a superset of a specified collection.</summary>
        /// <returns>true if the current set is a superset of <paramref name="other"/>; otherwise, false.</returns>
        /// <param name="other">The collection to compare to the current set.</param>
        /// <exception cref="ArgumentNullException">
        /// <paramref name="other"/> is null.
        /// </exception>
        bool IsSupersetOf(IEnumerable<T> other);

        /// <summary>Determines whether the current set overlaps with the specified collection.</summary>
        /// <returns>true if the current set and <paramref name="other"/> share at least one common element; otherwise, false.</returns>
        /// <param name="other">The collection to compare to the current set.</param>
        /// <exception cref="ArgumentNullException">
        /// <paramref name="other"/> is null.
        /// </exception>
        bool Overlaps(IEnumerable<T> other);

        /// <summary>Determines whether the current set and the specified collection contain the same elements.</summary>
        /// <returns>true if the current set is equal to <paramref name="other"/>; otherwise, false.</returns>
        /// <param name="other">The collection to compare to the current set.</param>
        /// <exception cref="ArgumentNullException">
        /// <paramref name="other"/> is null.
        /// </exception>
        bool SetEquals(IEnumerable<T> other);
    }
}

インジェクションヘルパーとのこの契約をnuget（https://www.nuget.org/packages/ClrCoder.Collections.ReadOnlySet）に公開しました。
気軽に使用して、ここで問題を送信してください： https ：
それが少し人気になる場合（おそらく数回の改良の後）、CoreFXチームにこの改善を提案することができます。

@terrajobst既存のクラスのcompatが新しいインターフェースを実装しても大丈夫ですか？

@safern List<T>にIReadOnly追加される前例があります。

では、次の.NET Frameworkリリースを追加する予定ですか？

この作品はいつ着陸するのですか？ タイムラインはありますか？

https://www.nuget.org/packages/System.Collections.Immutable/
不変のコレクションのフルセット）

わかった。 これはあまりにも長い間ここにありました。 私はそれを非常に必要としており、それからこれにどのようにアプローチするかについての方法を提案したいと思います。

これらすべてを公開する代わりに：

IEqualityComparer<T> Comparer { get; }
bool IsProperSubsetOf(IEnumerable<T> other);
bool IsProperSupersetOf(IEnumerable<T> other);
bool IsSubsetOf(IEnumerable<T> other);
bool IsSupersetOf(IEnumerable<T> other);
bool Overlaps(IEnumerable<T> other);
bool SetEquals(IEnumerable<T> other);

そして、顧客にこれらのメンバーの実装を強制するために、最も重要なものを追加しましょう。

public interface IReadOnlySet<out T> : IReadOnlyCollection<T>
{
    bool Contains<T>(T item);
}

そしてそれ以上は何もありません。 そのような必要がある場合は、将来いつでもAPIを追加できます。 しかし、それを削除することはできないので、この提案。

次に、このインターフェイスをISet<T>拡張されたインターフェイスのリストに追加します。

ドキュメントから

ISet<T> ：このインターフェースは、固有の要素と特定の操作を持つコレクションであるセットを実装するためのメソッドを提供します。 HashSetおよびSortedSetコレクションはこのインターフェースを実装します。

コードから

ISet<T>インターフェースには、すでにICollection<T>介して定義されたbool Contains<T>(T item);メソッドがあります。 また、 int Count { get; }経由でICollection<T>ます。

したがって、次のようになります。

public interface ISet<T> : ICollection<T>, IEnumerable<T>, IEnumerable, IReadOnlySet<T>

些細な変更、議論することはほとんどなく、大きなメリット。

それを実現させましょう。 そのようなプルリクエストが受け入れられ、マージされるかどうかを教えてください。 それで作成できます。

@karelz @terrajobst @safern @ianhays

辞書のキーコレクションを読み取り専用のセット操作に使用したいという現実の問題に取り組んでいるときに、この議論を見つけました。 その場合をサポートするために、ここに私が提案するAPIがあります。

理論的根拠

提案されたAPI

 namespace System.Collections.Generic {
+    public interface IReadOnlySet<out T> : IReadOnlyCollection<T>, IEnumerable, IEnumerable<T> {
+        bool Contains(T value);
+        bool IsProperSubsetOf(IEnumerable<T> other);
+        bool IsProperSupersetOf(IEnumerable<T> other);
+        bool IsSubsetOf(IEnumerable<T> other);
+        bool IsSupersetOf(IEnumerable<T> other);
+        bool Overlaps(IEnumerable<T> other);
+        bool SetEquals(IEnumerable<T> other);
+    }
-    public class HashSet<T> : ICollection<T>, IDeserializationCallback, IEnumerable, IEnumerable<T>, IReadOnlyCollection<T>, ISerializable, ISet<T> {
+    public class HashSet<T> : ICollection<T>, IDeserializationCallback, IEnumerable, IEnumerable<T>, IReadOnlyCollection<T>, ISerializable, ISet<T>, IReadOnlySet<T> {
     }
-    public class SortedSet<T> : ICollection, ICollection<T>, IDeserializationCallback, IEnumerable, IEnumerable<T>, IReadOnlyCollection<T>, ISerializable, ISet<T> {
+    public class SortedSet<T> : ICollection, ICollection<T>, IDeserializationCallback, IEnumerable, IEnumerable<T>, IReadOnlyCollection<T>, ISerializable, ISet<T>, IReadOnlySet<T> {
     }
+    public class ReadOnlySet<T> : ICollection<T>, IEnumerable, IEnumerable<T>, IReadOnlyCollection<T>, IReadOnlySet<T>, ISet<T> {
+        public int Count { get; }
+        public ReadOnlySet(ISet<T> set);
+        public bool Contains(T value);
+        public bool IsProperSubsetOf(IEnumerable<T> other);
+        public bool IsProperSupersetOf(IEnumerable<T> other);
+        public bool IsSubsetOf(IEnumerable<T> other);
+        public bool IsSupersetOf(IEnumerable<T> other);
+        public bool Overlaps(IEnumerable<T> other);
+        public bool SetEquals(IEnumerable<T> other);
+    }
     public class Dictionary<TKey, TValue> {
-        public sealed class KeyCollection : ICollection, ICollection<TKey>, IEnumerable, IEnumerable<TKey>, IReadOnlyCollection<TKey> {
+        public sealed class KeyCollection : ICollection, ICollection<TKey>, IEnumerable, IEnumerable<TKey>, IReadOnlyCollection<TKey>, IReadOnlySet<TKey> {
+            public bool IsProperSubsetOf(IEnumerable<TKey> other);
+            public bool IsProperSupersetOf(IEnumerable<TKey> other);
+            public bool IsSubsetOf(IEnumerable<TKey> other);
+            public bool IsSupersetOf(IEnumerable<TKey> other);
+            public bool Overlaps(IEnumerable<TKey> other);
+            public bool SetEquals(IEnumerable<TKey> other);
         }
     }
 }

未解決の質問

• 一般的にインスタンス化されるジェネリック型のコードサイズコストを考えると、これらのメソッドをDictionary<TKey, TValue>.KeyCollection追加することは許容できますか？ こちらをご覧ください。
• IReadOnlySet<T> 、 SortedDictionaryやImmutableDictionaryなどの他のDictionary KeyCollection IReadOnlySet<T>に実装する必要がありますか？

更新

• 削除されたTryGetValue 、それはでないとしてISet<T> 、そのようにしてリベース潜在的に、これまで妨げるISet<T>実装するためにIReadOnlySet<T> 。
• ReadOnlyCollection<T>類似したReadOnlySet<T>クラスを追加しました。

@TylerBrinkleyスレッドにAPIプロポーザルを追加してございます。 理論的根拠とユースケースを追加していただけませんか？ レビューの準備ができているとマークして、APIエキスパートに決定させることができるようにするには？

@TylerBrinkleyは、IReadOnlySetにEqualityComparerプロパティを含めることを忘れないでくださいインターフェース。 それらは現在、CoreFXの辞書とセットでは見落とされていますが、それは問題です。

@dmitriyse IEqualityComparer<T>プロパティのみのゲッターはどのような用途になりますか？ あなたはそれで何をしますか？

ディクショナリとセットは、正しいコレクションの複製を可能にするために、EqualityComparersを報告する必要があります。
残念ながら、私はこの問題がどこで議論されたかを忘れました。

クローンを作成している場合、具体的なタイプを使用していませんか？ インターフェイスがIEqualityComparer<T>をサポートする必要があるのはなぜですか？

たとえば、文字列と大文字と小文字を区別しない等式比較子を設定した場合、正しいEqualityComparerを指定せずに新しいHashSetを作成すると例外が発生します。 指定されたセットでどのEqualityComparerが使用されているかわからない場合があります。

クローンだけではありません。 はるかに一般的なシナリオは、2つのセットを比較することだと思います。Containsを使用して最適な比較を実装するには、両方が同じ比較子を使用することを知っておく必要があります。 このスレッドには例があると思います。

そうは言っても、IReadOnlySetにContainsメソッドだけを追加したいのです。 セット比較を一般的に実装できると便利ですが、セットへの読み取り専用参照が必要なほど一般的ではありません。

iOS用のOutlookを入手するhttps://aka.ms/o0ukef

投稿者：タイラーブリンクリー[email protected]
送信日：2018年5月10日木曜日6:21:52 AM
宛先：dotnet / corefx
Cc：アーロンマイヤーズ; 言及
件名：Re：[dotnet / corefx]インターフェイスIReadOnlySetを追加し、HashSet、SortedSetに実装させてください（＃1973）

クローンを作成している場合、具体的なタイプを使用していませんか？ インターフェイスがIEqualityComparerをサポートする必要があるのはなぜですか。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してくださいhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdotnet%2Fcorefx%2Fissues%2F1973%23issuecomment-388051258&data=02 ％7C01％7C％7Cc45ea16cd3034ddd69d808d5b678ff33％7C84df9e7fe9f640afb435aaaaaaaaaaaa％7C1％7C0％7C636615553141417289＆SDATA = xRI27JtyaAwnZ2anY05oTlxmPY5AaGVl％2BRdXK2uR0％2F8％3D＆0 =予約済み、またはスレッドをミュートhttps://eur01.safelinks.protection.outlook.com/?url=https%3A% 2F％2Fgithub.com％2Fnotifications％2Funsubscribe-AUTH％2FAMuQLmqboBWyHweWHSUoE1YM2OrfHZZxks5txD7wgaJpZM4E9KK-＆データ= 0.02％7C01％7C％7Cc45ea16cd3034ddd69d808d5b678ff33％7C84df9e7fe9f640afb435aaaaaaaaaaaa％7C1％7C0％7C636615553141417289＆SDATA = hLtAXEyFNVEgWike6tMwAfUVC％2BucyjXUDwoLOLDV5gk％3D＆= 0予約。

同意します。セット内で検出される可能性のある重複の種類（大文字と小文字を区別する、大文字と小文字を区別しないなど）を判断する唯一の方法は、比較子を公開することです。

これらすべてのメソッドをDictionary<TKey, TValue>.KeyCollection追加すると、コードサイズにかなりのコストがかかるため、私の提案は受け入れられないと思い始めています。 一般的にインスタンス化されるジェネリック型への新しいAPIの追加については、この

IReadOnlySet比較対象を置くことはできないと思います。

SortedSetはIComparer HashSet取り、 IEqualityComparer HashSetはIEqualityComparer取ります。

良い点は、比較者は、一般的なインターフェースに属さない実装の詳細と見なすことができます。

iOS用のOutlookを入手するhttps://aka.ms/o0ukef

投稿者：コーリーネルソン[email protected]
送信日：2018年5月10日木曜日17:04:06
宛先：dotnet / corefx
Cc：アーロンマイヤーズ; 言及
件名：Re：[dotnet / corefx]インターフェイスIReadOnlySetを追加し、HashSet、SortedSetに実装させてください（＃1973）

IReadOnlySetに比較子を配置することはできないと思います。

SortedSetはIComparerを取り、HashSetはIEqualityComparerを取ります。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してくださいhttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdotnet%2Fcorefx%2Fissues%2F1973%23issuecomment-388221165&data=02 ％7C01％7C％7C0ef6d84125be4c450fdc08d5b6d2b70a％7C84df9e7fe9f640afb435aaaaaaaaaaaa％7C1％7C0％7C636615938478979295＆SDATA = PHkDQPiJBEIks8yNyIA7vKODM％2BkMFI4PRX4lUUBu％2Bi0％3D＆0 =予約済み、またはスレッドをミュートhttps://eur02.safelinks.protection.outlook.com/?url=https%3A% 2F％2Fgithub.com％2Fnotifications％2Funsubscribe-AUTH％2FAMuQLu5JGLcqrpMyGWLygbCsaSQSXFgNks5txNV2gaJpZM4E9KK-＆データ= 0.02％7C01％7C％7C0ef6d84125be4c450fdc08d5b6d2b70a％7C84df9e7fe9f640afb435aaaaaaaaaaaa％7C1％7C0％7C636615938478979295＆SDATA = 9pnuMULuDu9HWb7un％2FWYq6iYdjTKFsjN7nKiToaeHkk％3D＆= 0予約。

IUnorderedSetとIOrderedSetインターフェースを追加することにIUnorderedSet価値があるかもしれませんが、それがIReadOnlySetプッシュを狂わせたくはありません。

私は@pgolebiowskiの提案が好き

c# public interface ISetCharacteristic<in T> { bool Contains(T item); }

これは、間隔（実数）などの非可算集合にも適しています。 それとIReadOnlySet間では、 ICountableSet （別名IEnumerableSet ）、 IUnorderedSet 、 IOrderedSetなどの他のいくつかのインターフェースに収まる可能性があります。

ただし、 IReadOnlySetだけで、現在利用可能なものよりも大幅に改善されることに同意してください。

@NickRedwoodの+1

オープンして3年以上になります。 アプローチを変えてこれを実現してください。 @NickRedwoodによって言及された変更を導入すると、このスレッドで説明している他のすべての機能強化が可能になります。 すべてのアプローチは、この1つの些細なことについて同意します。 それでは、基本的なこの1つの些細なことを追加してから、すべてオプションである可能性のある拡張機能について別の問題を作成しましょう。

@TylerBrinkley @safern @karelz @terrajobst

ContainsメソッドだけでIReadOnlySet<T>インターフェースにそれほどメリットがあるとは思いません。 その方法は有用であるが、それは既にに含まれていますICollection<T>も持っているインタフェースIsReadOnlyプロパティの変更方法かどうかを示すことを意図ICollection<T>サポートされています。 ICollection<T>を実装し、 IsReadOnlyがtrue返すようにするだけです。 サポートが期待される他の機能は、列挙可能なCountプロパティと、制限が多すぎないように見えるCopyToメソッドだけです。

提案されたIReadOnlySet<T>がIReadOnlyCollection<T>基づいて実装されることを非常に嬉しく思います。これは、現在利用可能なものを大幅に改善することになるでしょう。 （@TylerBrinkleyは-あなたが意味するものと仮定IReadOnlyCollection<T>のではなく、 ICollection<T> 。

私はもっ​​と基本的なインターフェースの側に誤りがあると思います、そしてもしSetのためのものがあったなら、それはContainsメソッドを持つ単一メソッドインターフェースでしょう。 それは良い数学的基礎を持っており、とてもきれいです。 しかし、既存のクラスに改装するとき、私は少ない方が良いという後付けを受け入れ、そしてがあった場合は1つのインターフェイスだけが、その後改造するIReadOnlySet<T>に基づいてIReadOnlyCollection<T>それをする必要があります。

IReadOnlyCollection<>は.Containsがありません。これは、共変するのを妨げるためです。

良い点です。以前の投稿を反変になるように修正しました。 IReadOnlySet<T>は、スレッドの早い段階で投稿されたアプローチが使用されない限り、不変である必要があり、それについてはよくわかりません。

@TylerBrinkley個人的には、私はIsReadOnlyプロパティのファンではありません。むしろ、実行時ではなくコンパイル時にこの情報を知ってもらいたいと思います。 IReadOnlyCollection<T>インターフェイスを参照している場合でも、コレクションを介した潜在的な反復ではなく、ルックアップが高速になることを発信者または呼び出し先が知っておくと便利だと思います。 「セット」はそれを意味します。

Containsメソッドだけでは、 Setが何をすべきかを定義するのではなく、 Collectionが何をすべきかを定義します。 つまり、 ContainsはISetメンバーではなく、 ISet継承するICollectionメンバーです。 ISetの他のメンバーは、 Setが何をすべきかを定義する必要があります。 ほとんどの人がおそらくContainsメソッド専用のセットを使用していることを理解していますが、セットにはそれだけではありません。

@TylerBrinkleyしかし、この時点でIReadOnlyCollection<T>.Contains(T)を定義することさえ可能ですか？ 私はそうは思わなかった。 そのため、唯一のオプションはIReadOnlySet<T>を導入することであり、導入された場合は、 IReadOnlySet<T>.Contains(T)がその上で宣言されていることを確認してください。

@ jnm2は言う：

IReadOnlyCollection<>は.Containsがありません。これは、共変するのを妨げるためです。

これが今の私にとって最大の問題のようです。 IReadOnlyCollection<T>が共変である場合、 IReadOnlySet<T>が不変であるのは奇妙なことです。 多くの既存のIReadOnly*インターフェースは、書き込み可能なインターフェースが必然的に不変であるout Tであるように注意深く設計されたようです。 私たちのほとんどは、 IReadOnlySet<T>が少なくともContains(T)メソッドを宣言することを望んでいますが、それでもそれが共変になるのを防ぎます。

ICollection本当にContains(T)を定義するのに適切な場所である場合、それは可能ですか？ たぶんIReadOnlyProbableCollection<T>.Contains(T)は不変で、 Collection<T>とHashSet<T>によって実装されますか？

@NickRedwoodのISetCharacteristic<T>の提案は、おそらくもっときれいに思えます。 これには、便利なCountを実装しないという利点もあります。

個人的には、IsReadOnlyプロパティのファンではないので、実行時ではなくコンパイル時にこの情報を知ってもらいたいと思います。

その男は上手に話し、彼にもっとワインを注ぐ。

@binki IReadOnlyCollection<T>はIReadOnlySet<T> Containsメソッドが必要であることに同意しますが、他のすべての非変更ISet<T>も考えます。

上記のDictionary.KeyCollectionユースケースの他に、このインターフェースを追加するために他にどのようなユースケースを思い付くことができますか？

OK、APIデザインは次のように見えます：

public interface IReadOnlySet<T> : IReadOnlyCollection<T> {    
    bool Contains(T item);
}

それは誰もが同意できるように見えるデザインの唯一の共通部分です。

ここでデザインを終了します。 将来拡張したい場合は、別の問題で拡張してください。 これは、製品に含まれるべき最も重要な機能です。

誰が賛成、誰が反対ですか？

@ashmindの提案が好きです。 技術的にはIReadOnlySet<TKey>ため、Dictionary.Keysがこのインターフェイスを実装できれば素晴らしいと思います。

これをapi-ready-for-reviewとしてマークしていただけますか？ 私は自分自身がこのインターフェースを再び必要としていることに気づきました、そしてそれはまだそこにありません。

なぜこれがまだ実装されていないのですか？

[編集]お詫び-私の最初の返信は別のAPIと混同さ​​れていました。 私はこれについて強い意見を持っていません、テキスト編集。 混乱させて申し訳ありません！

なぜこれがまだ実装されていないのですか？

APIはまだエリア所有者の注目を集めていません-@ safern。 コレクションの優先順位リストでどれだけ高いかわかりません。 賛成票の数はかなり多いです。
真実は、現在.NET Core 3.0をロックダウンしているため、3.0にとって重要ではないため、少なくとも次のリリースを待つ必要があるということです。

これが箱から出して提供されていないことにも驚いています。

不変のデータ構造は、コードの保守性を向上させるのに大いに役立ちますが、セマンティクスを指定し、さまざまな実装を連携させる標準ライブラリのインターフェイスなしでは使用できません。

これがないと、パラメータ/戻り値として不変セットを使用することを意味する各ライブラリは、効率が低く意味的に正しくないIEnumerableを使用するか、他の人と互換性のない独自のインターフェイス/クラスを署名に使用する必要があります。

Containsルックアップに関して効率的で、パラメーター/戻り値の具体的なタイプを指定しないようにする回避策があるかどうか知りたいです。 頭の中で考えられる最善の方法は、署名でIEnumerableを使用し、ReadOnlyDictionary.Keysを渡すことですが、特にライブラリでは、これは少し厄介なようです。 LinqのEnumerable.ContainsはContainsのコレクション実装を使用するため、これは互換性がありながら効率的であるはずですが、パフォーマンスの低い実装の使用につながる可能性のある意図を伝達しません。

@ adamt06あなたはISet<T>探しています。

@scalablecoryあなたは正しいです、不変の実装で、1つあります： ImmutableHashSet<T>

誰かがICollectionの理由を知っている/理解していますかIReadOnlyCollectionを拡張しません??
これはこのスレッドに少し関係があると思いました。 私の代わりに新しいスレッドを開きます。 多分私は何かを誤解しているだけです。

別の考えですが、完全にトピックから外れています。ReaOnlyCollectionに次の機能がないのはなぜですか。

c# bool Contains(T item); void CopyTo(T[] array, int arrayIndex);

重大な変更と関係がありますが、詳細は覚えていません。

ReadOnlyCollectionには次のものがあります。
https://docs.microsoft.com/en-us/dotnet/api/system.collections.objectmodel.readonlycollection-1.contains
https://docs.microsoft.com/en-us/dotnet/api/system.collections.objectmodel.readonlycollection-1.copyto

ああ、IReadOnlyCollectionにそれらがないという意味だと思います。 それ以外の場合、インターフェースは共変ではない可能性があるためです。

よくわかりませんが、下位互換性の問題を引き起こす明示的なインターフェイスの実装に関係している可能性があります。 既存のインターフェースを更新して他のインターフェースから継承することが問題になる理由はわかりますが、新しいインターフェースIReadOnlySet<T>を作成し、 HashSet実装させることが問題になる理由はわかりません。

わかった。 しかし、それでもICollectionは表示されませんあってはなりません：
c# ICollection<T> : IReadOnlyCollection<out T>
読み取り/書き込みコレクションが読み取り専用コレクションの拡張でもないのはなぜですか？

@ generick0

わかった。 しかし、それでもICollectionが次のようになってはいけないことがわかりません。

ICollection<out T> : IReadOnlyCollection<out T>

読み取り/書き込みコレクションが読み取り専用コレクションの拡張でもないのはなぜですか？

まず、 ICollection<T>にはメンバー.Add(T item)があるため、 ICollection<T> ICollection<out T>を宣言できないことに注意してください。

次に、 ICollection<T>は.net-2.0に表示され、 IReadOnlyCollection<out T>は.net-4.5に表示されることに注意してください。 ICollection<T>を実装するようにコードをコンパイルし、次にICollection<T>を変更して新しいインターフェイスを実装すると、 ICollection<T>のみを実装するものにはその機能がないため、既存のコンパイル済みバイナリは実行時に破損します。 IReadOnlyCollection<T>スロットはコンパイラによって（おそらく自動的に）埋められます。 これは、 ICollection<T>がIReadOnlyCollection<T>実装できなかった互換性の問題です。

私はこれがこのSOの答えによって明確に対処されているとは思いませんが、それに対するSOがあります： //stackoverflow.com/a/14944400 。

@binki "ICollection"ICollectionに修正、私のタイプミスを指摘してくれてありがとう。
DotNetStandard inet461。 そして、これが変化のあるべき場所です。 ネットスタンダード2+

繰り返します...
読み取り/書き込みコレクションが読み取り専用コレクションの拡張でもないのはなぜですか？

そして、露出を減らすために、コレクションをたとえば「ToArray（）」にキャストする必要があるのはなぜですか？

そして、あなたは物事を壊すことなく、より高いバージョンで新しいインターフェースを追加することができるからです。 ICollectionには、すでにIReadOnlyCollectionメソッドが実装されています。 注意が壊れるべきです、...：-/

@ generik0あなたが考えているソースの互換性を壊さないように見えます[考えていませんでした。 ]ですが、C＃ではなくILテーブルで機能するバイナリ互換性が失われます。

OK @ jnm2ありがとう。
私は今、私のオフトピックの暴言を止めます、ただそれが悪いアーキテクチャだと思います。 聞いて/説明してくれてありがとう:-)

@ jnm2

@ generick0あなたが考えているソースの互換性を壊さないように見えますが、C＃ではなくILテーブルで機能するバイナリの互換性を壊します。

（申し訳ありませんが）ソースが.net-4.5より前のICollection<T>を明示的に実装している場合は、ソースの互換性も損なわれます。 IReadOnlyCollection<T>.Countを明示的に実装できなかったため、クラスのコンパイルに失敗し始めました。 ただし、バイナリの互換性は、さまざまな.netバージョンをターゲットにできないため、より大きな問題になります（.net-4.5以上で実行するには、.net-2未満とは異なるバイナリを使用する必要があります。古いフレームワークだけをターゲットにするのではなく、両方をターゲットにする必要があります）。

ICollection<T>が.NET Core 3.0以降のIReadOnlyCollection<T>を実装できるかどうか、C＃8にデフォルトのインターフェイス実装サポートが追加されているかどうか疑問に思っています。

たぶん拡張が必要です、そしてそれは少なくとも同じコレクションです。 つまり、reaadonlycollectionに無数またはicollectionを取得する必要がある場合...何か考えはありますか？

[ @ jnm2コメントで編集]
c# public static class CollectionExtensions { public static IReadOnlyCollection<T> CastAsReadOnlyCollection<T>(this IEnumerable<T> collection) { if((collection is IReadOnlyCollection<T> readOnlyCollection )) { return readOnlyCollection ; } throw new ArgumentException($"{collection.GetType()} not supported as readonly collection"); } }

@ generick0そのメソッドを呼び出す代わりに、 enumerable as IReadOnlyCollection<T> ?? throw ...または(IReadOnlyCollection<T>)enumerable使用しないのはなぜですか？

@ jnm2omg 。 あなたが正しいです。 時々あなたは明確な絵を見ず、物事を過度に複雑にします!!!

簡単にするために、私はまだ拡張機能を呼び出します;-)
どうも....

ここの状況はどうですか？ このインターフェースを標準のlibに入れて、HashSet <>に実装してもらいたいです。

Shapesの提案が（うまくいけば）実装されるまで、もう少し待つのが最善の策のようです。 次に、必要なセットタイプを表す形状のグループを作成し、 HashSet<T>などの既存のセットがそれらに準拠するように実装を提供できます。

次に、これを正確に行うためのコミュニティライブラリが出現し、さまざまなタイプのセット（意図的（述語）および拡張（リスト）、順序付き、部分的順序付き、順序なし、可算、数え切れないほど無限、数えられない無限、おそらくRationalのような数学ドメイン）をすべてカバーします。 、自然数など）をさまざまな形として、これらのセットに対して、およびこれらのセット間で定義されたすべての結合、共通部分、カーディナリティメソッドを使用します。

それは私には5年先のように聞こえます。 1日で実装できる単純な変更が、1000倍大きい、まだ指定されていない機能が発生しない可能性があるのを待つ必要があるのはなぜですか？

それは私には5年先のように聞こえます。 1日で実装できる単純な変更が、1000倍大きい、まだ指定されていない機能が発生しない可能性があるのを待つ必要があるのはなぜですか？

私はIReadOnlySet<T>の進展の欠如に対応しているだけです-この問題は結局4年後にすでに開かれています。

Microsoftのやり方：最も単純で便利なことには数十年かかります。 それは気が遠くなる。 5年と数えます。

さらに面白いのは、彼らがここにそれを持っているということです
https://docs.microsoft.com/en-us/dotnet/api/microsoft.sqlserver.management.sdk.sfc.ireadonlyset-1

@terrajobstの考え？

• 私たちは一般的に、これは確かに私たちのインターフェース階層の穴であると信じています。 インターフェイスを追加し、既存のセット実装に実装することに焦点を当てることをお勧めします。 ISet<T>をIReadOnlySet<T> ISet<T>拡張させることはできません（他の可変インターフェースでは実行できなかったのと同じ理由で）。 後の段階でReadOnlySet<T>を追加できます。 IReadOnlySet<T>がISet<T>から可変APIを差し引いたものであることを再確認する必要があります。
• また、 ImmutableSortedSet<T>とImmutableHashSet<T> （およびそれらのビルダー）にIReadOnlySet<T>を実装する必要があります
• ISet<T>他の実装をスキャンする必要があります。

 namespace System.Collections.Generic {
+    public interface IReadOnlySet<out T> : IReadOnlyCollection<T>, IEnumerable, IEnumerable<T> {
+        bool Contains(T value);
+        bool IsProperSubsetOf(IEnumerable<T> other);
+        bool IsProperSupersetOf(IEnumerable<T> other);
+        bool IsSubsetOf(IEnumerable<T> other);
+        bool IsSupersetOf(IEnumerable<T> other);
+        bool Overlaps(IEnumerable<T> other);
+        bool SetEquals(IEnumerable<T> other);
+    }
-    public class HashSet<T> : ICollection<T>, IDeserializationCallback, IEnumerable, IEnumerable<T>, IReadOnlyCollection<T>, ISerializable, ISet<T> {
+    public class HashSet<T> : ICollection<T>, IDeserializationCallback, IEnumerable, IEnumerable<T>, IReadOnlyCollection<T>, ISerializable, ISet<T>, IReadOnlySet<T> {
     }
-    public class SortedSet<T> : ICollection, ICollection<T>, IDeserializationCallback, IEnumerable, IEnumerable<T>, IReadOnlyCollection<T>, ISerializable, ISet<T> {
+    public class SortedSet<T> : ICollection, ICollection<T>, IDeserializationCallback, IEnumerable, IEnumerable<T>, IReadOnlyCollection<T>, ISerializable, ISet<T>, IReadOnlySet<T> {
     }
 }

やれ、あえて！

@terrajobst

ISet<T>をIReadOnlySet<T> ISet<T>拡張させることはできません（他の可変インターフェースでは実行できなかったのと同じ理由で）。

これは、デフォルトのインターフェイスメソッドを使用しても当てはまりますか？ それはhttps://github.com/dotnet/corefx/issues/41409を閉じる必要があるという意味ですか？

@terrajobst

ISet<T>をIReadOnlySet<T> ISet<T>拡張させることはできません（他の可変インターフェースでは実行できなかったのと同じ理由で）。

これは、デフォルトのインターフェイスメソッドを使用しても当てはまりますか？ それはdotnet / corefx＃41409を閉じる必要があるという意味ですか？

これについて話し合いました。 以前はDIMが、ソリューションを検討したところ、通常はシャードダイアモンドが生成され、あいまいな一致が発生すると結論付けました。 しかし、これは最近挑戦されたので、私はそれを書き留めて、それが実際に機能しているかどうかを確認する必要があると思います。

@terrajobst / @danmosemsft誰かがこれに割り当てられていますか？

そして、私たちが達成したい仕事を明確にするための@terrajobstは次のとおりです。
`` `
IReadOnlySetも実装する必要がありますImmutableSortedSetでおよびImmutableHashSet（およびそのビルダー）
ISetの他の実装をスキャンする必要があります。
「」
上記のインターフェースをHashSet、SortedSetに実装するだけでなく。

スキャンはただ何かを探して、疑わしいと思われる場合はそれを表示します。

これがまだ手に入るなら、私は興味があるでしょう

@Jlalondいいえ、あなたに割り当てられました。 申し出に感謝。

@danmosemsft @terrajobst
ただの更新。 私はこれに取り組んでおり、プライベートコアLibにインターフェイスを追加し、collections.genericと不変のこれを取得する方法を見つけました。

ダンを頭から知っている場合の最後の質問ですが、これのためにモノに変更を加える必要がありますか？ corefxがどこで終わり、monoがどこから始まるのかについては洞察力がありません。 だからあなたがそれがいくつかの独立した研究から私を救うことができることを知っているなら

@JlalondMonoに変更を加える必要はありません。 Monoランタイムをこのリポジトリに移動する理由の一部は、CoreCLRまたはMonoランタイムのいずれかでまったく同じライブラリをシームレスに使用できるようにするためです。 分岐するコアライブラリのごく一部のみがあります。
coreclrsrcSystem.Private.CoreLibとmononetcoreSystem.Private.CoreLib。 （コアライブラリのほとんどは、librariesSystem.Private.CoreLibから共有されます）。 したがって、それに触れない限り、影響はありません。

@danmosemsft説明してくれてありがとう、私はこれがすぐに行われることを望んでいます。

ねえ@danmosemsftはこれをフォローアップするだけです。 CoreLibはsrcアセンブリに組み込まれていますが、参照されている変更を確認できます。 ただし、refアセンブリは変更を検出していないようです。 これが私を悩ませているすべてですが、ドキュメントに情報が見つかりません。 私がこれを成し遂げることができるようにあなたが私に与えることができる人やポインター（つまり、5年後）

＃32488で対処