불변하게 만드는 언어 구성이 있다면 좋지 않을까요? 그렇다면 우리는 이러한 마법의 인터페이스를 가질 필요가 없을 것입니다.

@whoisj 어떤 언어인가요? CLR에는 수십 가지가 있습니다.

잠재적인 언어 기능이라고 해도 메타데이터 표현이 필요합니다. 이 경우 마커 인터페이스(또는 행동 인터페이스)가 가장 좋습니다. 새 메타데이터 항목을 통해 컬렉션 유형의 불변성을 전달하려는 시도는 CLR이 임의의 클래스가 내부적으로 작동하는 방식에 대한 가정을 해서는 안 되기 때문에 적절하지 않은 것 같습니다. 배열).

@whoisj 나는 이것이 적어도 미래의 C# 버전 중 하나에 대해 고려

또한 변경할 수 없는 컬렉션을 이미 사용할 수 있습니다.

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

완전히 변경할 수 없는 컬렉션을 얻으려면 immutable T 를 정의한 다음 이를 사용하여 Immutable...<T> 컬렉션을 선언하면 됩니다.

@HaloFour 우리는 전에 이 길을 가본 적이 있습니다 : this )".

@dsaf 절대적으로! 또 다른 문제에서 나는 쓰기 가능한 요소의 읽기 전용 컬렉션을 사용할 수 있도록 읽기 전용에 대한 쓰기 가능한 반항어를 제안했습니다. readonly Bag<writable Element> 라인을 따라 뭔가.

& 로 표시된 참조는 컴파일러에서 변경할 수 없는 것으로 처리하도록 제안했습니다. 나는 여전히 컴파일 시간 확인이 필요하고 런타임 보장이 아닌 논리의 컴파일 시간 확인을 추구하기 때문에 CLR 자체에서 반드시 시행해야 한다고 생각합니다. 이것은 개발자가 변경 불가능하기를 원하는 모든 참조를 다루지만 호출 기준입니다.

@whoisj 아마도, 그러나 그것은 꽤 접선적이며 dsaf가 오늘 오후에 분기/PR할 수 있는 것에서 세 개의 다른 팀에 걸쳐 노력을 포함하는 것으로 이 요청을 바꿉니다.

또한 이것을 컴파일러 문제로 취급하고 있습니다. 이 시점에서 관련 컴파일러(JIT 컴파일러 이상)는 없으며 검증자만이 "부적절한" 코드가 실행되는 것을 방지할 수 있습니다. 불변성의 기존 런타임 메커니즘인 initonly 필드도 검증을 건너뛰면(또는 리플렉션을 통해) 쉽게 무력화될 수 있습니다.

C# 언어와 컴파일러가 "순수한" 메서드를 더 잘 지원할 수 있다면 좋을 것이라는 데 동의합니다. PureAttribute 속성

@HaloFour 박람회.

"순수" 또는 "const" 참조를 지원하는 일반적인 방법이 없다고 가정하면 제안된 것이 가장 좋은 대안이라고 생각합니다.

지금 필요한 경우 내 Commons 라이브러리(Commons.Collections https://github.com/yanggujun/commonsfornet/tree/master/src/Commons.Collections/Set )에 읽기 전용 세트 지원이 있습니다. 관리자는 이것이 광고라고 생각되면 이 게시물을 삭제하십시오... 제 제안은 오픈 소스 구현을 둘러보는 것입니다.

@yanggujun 좋은 라이브러리처럼 보이지만 추가 종속성을 피하기 위해 직접 롤링하겠습니다.

내 제안은 일부 오픈 소스 구현을 둘러보는 것입니다.

이것은 해결 방법이며 IReadOnlySet과 같은 기본 인터페이스는 실제로 .NET Framework 자체의 일부여야 합니다.

"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에 대해 더 많은 작업이 있습니까? 도움이 되고 누군가가 필요한 것을 지적할 수 있다면 이에 대해 시간을 할애하게 되어 기쁩니다.

@ashmind가 제안한 API는

ISet<T> 를 IReadOnlySet<T> 로 확장할 수 있습니까? IList<T> / IReadOnlyList<T> 발생하지 않았습니까?

그렇지 않다면, 그때 추가 고려해야 할 다른 변화를 가정 IReadOnlySet<T> 모든 인터페이스 목록에 ISet<T> 을 포함하여 corefx에서 구현 HashSet<T> , SortedSet<T> 과 System.Collections.Immutable 불변 대응.

@GiottoVerducci 에 동의해야 합니다. IReadOnlySet<T> 와 같은 이름을 사용하면 계약 기능이 선언되지 않고 계약 제한이 선언됩니다. 그런 다음 이러한 제한과 모순되는 다른 계약과 결합된 동일한 계약을 사용하는 것은 혼란스럽습니다. 계약 이름은 ​​구현자가 지원하는 것과 관련된 긍정적인 주장을 설명해야 한다고 생각합니다. IReadableSet<T> 와 같은 이름은 당연히 좋지 않지만 적어도 구현자가 하는 일을 더 잘 설명합니다.

@HaloFour 원칙적으로 동의하지만 IReadOnlyList<T> 와 같은 상황입니다. 일관성을 유지하는 것이 IMHO의 정밀도 증가보다 우선합니다.

@drewnoakes

이해하고 일관성이 중요합니다. 나는 그것이 ISet<T> 가 IReadOnlySet<T> 확장해서는 안되는 이유에 대해서도 대답한다고 생각합니다.

일관성을 유지하는 것이 IMHO의 정밀도 증가보다 우선합니다.

나는 그것이 ISet<T> 가 IReadOnlySet<T> 확장해서는 안되는 이유에 대해서도 대답한다고 생각합니다.

나는 당신이 요점을 놓치고 있다고 생각합니다. 이것이 ISet<T> 외에도 IList<T> , ICollection<T> , IDictionary<TKey, TValue> 도 읽기 전용 보기 인터페이스를 구현하도록 수정되어야 하는 이유입니다. 그렇지 않으면 모든 사람이 BCL의 직관적이지 않은 디자인을 해결할 때 계속해서 합니다 .

@binki

나는 동의하지 않는다. 내가 그것에 대해 좋아하지 않는 것은 read-_only_ 동작을 규정하는 계약이 read-_write_ 동작을 규정하는 계약에 의해 확장되는 것을 규정하는 것입니다. 네이밍이 틀리고 구성이 틀리네요. 하지만 여기 있습니다. 나는 둘 다 변경하기 위해 투표하고 싶지만 그것이 테이블에 있는지 의심됩니다.

@HaloFour

어떤 것에 대한 인터페이스를 얻을 때, 그것은 무언가에 대한 _view_입니다. 보기 자체는 _is_ 읽기 전용입니다. 유형 안전 코드를 작성하고 업캐스팅을 진행하지 않는다고 가정하면 읽기 전용인 것을 수신하면 모든 의도와 목적에 대해 읽기 전용입니다. 데이터가 변경되지 않는다는 보장은 없습니다. 파일을 읽기 전용으로 여는 것과 같습니다. 읽기 전용으로 열린 파일은 다른 프로세스에 의해 변경될 수 있습니다. 또는 관리자가 데이터에 대한 읽기-쓰기 보기를 갖고 사용자 아래에서 변경할 수 있는 웹 사이트의 페이지에 대한 읽기 전용 액세스와 같습니다.

여기에서 읽기 전용이 잘못된 용어로 간주되는 이유를 잘 모르겠습니다. 읽기 전용은 불변을 의미하지 _않습니다_. 필요한 경우 전체 nuget 패키지/다른 API(추가/제거가 새 개체를 생성하고 현재 인스턴스가 절대 변경되지 않음을 보장하므로 변경할 수 없음)가 있습니다.

비슷한 생각을 하고 있었습니다. .NET의 "읽기 전용"은 필드에 대해서도 매우 약한 보장입니다. do-over를 감안할 때 이 모든 것이 더 합리적일 것이라고 확신합니다. 지금은 실용적일 가치가 있습니다.

따라서 일반적으로 메서드가 IReadOnlySomething<T> 를 수락하면 일반적으로 수정하지 않을 것이라고 가정할 수 있습니다. 수신 메서드가 참조를 업캐스트하지 않는다는 보장이 없으며 인터페이스의 구현이 액세스될 때 내부적으로 자체 수정되지 않는다는 보장도 없습니다.

C++에서 const_cast 는 const 의 보장도 약화시킵니다. 이는 수치스러운 일이지만(요즘은 mutable 수정자가 있음) 실제로는 얼마나 유용한지 const 는 기능입니다. 당신은 당신이 무엇을 다루고 있는지 알아야합니다.

@binki 는 잘 구별됩니다. 이름에서 _Immutable_은 관련된 모든 사람에게 시간이 지남에 따라 안정성을 보장한다는 의미입니다.

IList<T> 가 IReadOnlyList<T> 확장하지 않는 이유에 대한 신뢰할 수 있는 출처가 있는 사람이 있습니까?

@binki

인터페이스는 보기가 아니라 계약입니다. 그 계약은 구현자의 능력을 선언합니다. 구현자가 실제로 이러한 기능을 구현하지 않으면 계약 위반으로 간주합니다. 해당 List<T> 클래스는 "is-a" IReadOnlyList<T> 라고 주장하지만 그렇지 않습니다. 그 능력이 부족합니다.

이 주제에 대해 여러 학파가 있습니다. 나는 인터페이스 상속이 유형 간의 "is-s-in" 관계를 더 엄격하게 따르는 학교에 분명히 속해 있습니다. 나는 확실히 인터페이스를 사용하여 구성에 대한 보다 세분화된 접근 방식을 지원하고 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://stackoverflow.com/a/35940240/429091

@HaloFour List<> 와 HashSet<> 가 ICollection<> 와 IReadOnlyCollection<> 때문에 우리는 이미 IReadOnly 가 접근이 아닌 접근을 가리키는 경로를 받아들였습니다. 능력. 이를 기반으로 IAnything IReadOnlyAnything 확장하는 것이 완벽합니다. IReadable 가 IReadOnly 보다 낫다는 데 동의하지만 이 시점에서 모두가 IReadOnly 를 IReadable _mean_ 이해하고 그대로 사용합니다. 사실, 나는 사물에 대해 두 가지 방식으로 생각하는 것이 내 생각에 그 어떤 것보다 인지 부하가 ​​더 크기 때문에 의도적으로 내 자신의 코드베이스에서 영속화하고 있습니다.

우리는 그 이름에 얽매여 있지만 그 이면의 개념은 우리가 구체 클래스에서 하는 것처럼 앞으로 모든 인터페이스가 IReadOnly 를 확장하는 것이 가능하기를 진정으로 바랄 만큼 충분히 강력합니다.

@ashmind 어떤 방법도 비교자를 사용하지 않는 것이 완벽하다고 생각합니다. 세트와 사전에서 비교자는 전체 객체의 구조를 결정하기 때문에 쉽게 교체할 수 있는 것이 아닙니다. 또한 CaseInsensitiveStringCollection 또는 특정 비교를 암시하는 컬렉션에 비교자를 전달하는 것은 이치에 맞지 않습니다.

(이미 사용 가능한 확장 메서드 보다 Contains(T, IEqualityComparer<T>) 더 효율적으로 구현하는 이상한 컬렉션의 경우 아마도 일회성 클래스 메서드일 것입니다. Contains(T, IEqualityComparer<T>) 가 일반적이라고 상상하기 어렵습니다. 전문화된 인터페이스로 끝나기에 충분하지만 그런 일이 일어나지 않도록 막을 방법은 없습니다.)

@jnm2

어떤 방법도 비교자를 사용하지 않는 것이 완벽하다고 생각합니다.

명확히하기 위해 비교자를 노출시키는 것이 아니라 노출해야한다고 말하고 싶었습니다. 모든 Set 또는 Dictionary에는 동일한 알고리즘이 있어야 하므로 인터페이스에 노출되었을 수 있습니다. 하지만 지금은 사용 사례가 기억나지 않습니다. 외부에서 제공하는 것과 동일한 비교자를 사용하여 집합을 만드는 것과 같은 것입니다.

이 토론에서 흥미로운 점들이 많이 나오지만, 이 스레드를 시작한 간단하고 분명한 제안과는 거리가 먼 것 같습니다. 이 문제가 해결되었으면 하는 바람에 실망스럽습니다.

OP가 말했듯이 IReadOnlySet 없이 IReadOnlyList가 추가되었을 때 컬렉션 유형 간의 패리티를 유지하지 못한 것은 불행한 일이며 많은 사람들이 해결 방법으로 자체 버전의 IReadOnlySet 인터페이스를 구현했습니다(저의 팀도 비슷한 해결 방법을 사용합니다). 이러한 해결 방법 인터페이스는 corefx 클래스에서 구현할 수 없기 때문에 이상적이지 않습니다. 이것이 프레임워크에서 이것을 제공하는 주요 이유입니다. HashSet이 있는 경우 이미 가지고 있는 개체를 복사하거나 래핑하지 않고 IReadOnlySet으로 사용할 수 있기를 바랍니다. 성능을 위해서는 적어도 이것이 종종 바람직합니다.

인터페이스의 이름은 분명히 IReadOnlySet이어야 합니다. 일관성은 IReadOnlyXXX 이름에 대한 모든 문제를 능가합니다. 그 배는 항해했습니다.

기존 인터페이스(IReadOnlyCollection)는 변경할 수 없습니다. .NET에 대한 이전 버전과의 호환성 요구 사항은 그러한 변경을 허용하지 않습니다. 비교자가 기존 IReadOnlyXXX 인터페이스에 노출되지 않은 것은 불행한 일이지만(이 경우에도 마찬가지임) 배가 다시 항해했습니다.

실용적인 관점에서 남아 있는 것처럼 보이는 유일한 질문은 인터페이스에 대한 이 두 가지 잠재적 정의 사이입니다.

@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 에서 _효율적인_ 방식으로 파생될 수 없다는 것입니다. 예를 들어 해시 테이블이 두 개인 경우 Contains 에 의존하면 구현에서 해시 일치가 아닌 중첩 루프를 사용하게 됩니다.

아마도 새로운 인터페이스인 IComparableSet<T> 에는 집합 작업이 포함될 수 있습니다.

몇 가지 집합 작업에 대해 IEnumerable<T> 대한 확장 메서드가 이미 있습니다.

@jnm2 HashSet에서 사용하는 이러한 메서드 의 IReadOnlySet 은

수정된 제안은 다음과 같습니다.

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

또는 Comparer가 별도의 인터페이스에 있을 수 있으며 설정 작업의 확장 메서드 구현은 두 개체가 인터페이스를 구현하고 동일한 비교자가 있는 경우에만 효율적인 경로를 사용합니다. IReadOnlyDictionary에 대해 동일한 접근 방식을 적용할 수 있습니다(사실, 아마도 동일한 인터페이스를 사용함). ISetComparable과 같은 것. 또는 @drewnoakes 에서 그림을 그러나 집합 연산자를 정의하는 대신 비교자를 정의합니다.

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

이 경우 IReadOnlySet은 다음을 정의하는 것으로 돌아갑니다.

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://github.com/dmitriyse/ClrCoder/issues
그것이 조금 대중화된다면(아마도 몇 차례의 개선 후에) CoreFX 팀에 이 개선 사항을 제안할 수 있습니다.

@terrajobst 기존 클래스가 새 인터페이스를 구현하는 데 적합합니까?

@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> : 이 인터페이스는 고유한 요소와 특정 작업이 있는 컬렉션인 집합을 구현하기 위한 메서드를 제공합니다. 해시셋및 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> 다른 구현 될 Dictionary KeyCollection 등의 SortedDictionary 또는 ImmutableDictionary ?

업데이트

• 제거 TryGetValue 그렇지에서의로 ISet<T> 가능성이 그 어느 리베이스 방지 할 수와 같은 ISet<T> 구현하기 IReadOnlySet<T> .
• 추가 ReadOnlySet<T> 유사하다 클래스 ReadOnlyCollection<T> .

@TylerBrinkley 스레드에 API 제안을 추가해 주셔서 감사합니다. 근거와 사용 사례를 추가하시겠습니까? 검토할 준비가 된 것으로 표시하고 API 전문가가 결정하도록 하시겠습니까?

@TylerBrinkley 는 상호 작용. 현재 CoreFX의 사전 세트에서 누락되었지만 문제입니다.

@dmitriyse getter는 IEqualityComparer<T> 속성만 사용할 수 있습니까? 그것으로 무엇을 하시겠습니까?

사전 및 집합은 올바른 컬렉션 복제를 허용하기 위해 EqualityComparers를 보고해야 합니다.
불행히도 이 문제가 논의된 곳을 잊어버렸습니다.

클로닝을 하면 콘크리트 타입으로 작업하지 않을까요? 인터페이스가 IEqualityComparer<T> 를 지원해야 하는 이유는 무엇입니까?

예를 들어 문자열과 대소문자를 구분하지 않는 평등 비교자를 사용하여 설정한 경우 올바른 EqualityComparer를 지정하지 않고 새 HashSet을 만들 때 예외가 발생합니다. 지정된 집합에서 어떤 EqualityComparer가 사용되었는지 알 수 없는 경우가 있습니다.

단순한 복제가 아닙니다. 훨씬 더 일반적인 시나리오는 두 세트를 비교하는 것입니다. Contains를 사용하여 최적의 비교를 구현하려면 둘 다 동일한 비교자를 사용한다는 것을 알아야 합니다. 이 스레드에 예가 있다고 생각합니다.

즉, IReadOnlySet을 아예 사용하지 않는 것보다 Contains 메서드만 사용하는 것이 좋습니다. Set 비교를 일반적으로 구현할 수 있으면 좋겠지만 Set에 대한 읽기 전용 참조가 필요한 만큼 일반적이지 않습니다.

iOS용 Outlook 다운로드 https://aka.ms/o0ukef

보낸 사람: Tyler Brinkley [email protected]
보낸 날짜: 2018년 5월 10일 목요일 오전 6:21:52
받는 사람: dotnet/corefx
참조: 아론 마이어스; 언급하다
제목: 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-% 2FAMuQLmqboBWyHweWHSUoE1YM2OrfHZZxks5txD7wgaJpZM4E9KK- 인증 및 데이터 = 02% 7C01 % 7C % 7Cc45ea16cd3034ddd69d808d5b678ff33 % 7C84df9e7fe9f640afb435aaaaaaaaaaaa % 7C1 % 7C0 % 7C636615553141417289 및 SDATA = hLtAXEyFNVEgWike6tMwAfUVC % 2BucyjXUDwoLOLDV5gk % 및 3D = 0 예약 .

동의합니다. 집합에서 찾을 수 있는 중복 유형(대소문자 구분, 대소문자 구분 등)을 알 수 있는 유일한 방법은 비교자를 노출하는 것입니다.

Dictionary<TKey, TValue>.KeyCollection 이러한 모든 방법을 추가하면 상당한 코드 크기 비용이 발생하므로 내 제안이 받아들여지지 않을 것이라고 생각하기 시작했습니다. 일반적으로 인스턴스화되는 제네릭 유형에 새 API를 추가하는 방법에 대한 이

나는 당신이 IReadOnlySet 에 비교자를 둘 수 없을 것이라고 생각합니다.

SortedSet 는 IComparer 를 받는 반면 HashSet 는 IEqualityComparer 받습니다.

좋은 점, 비교자는 일반 인터페이스에 속하지 않는 구현 세부 사항으로 간주될 수 있습니다.

iOS용 Outlook 다운로드 https://aka.ms/o0ukef

보낸 사람: Cory Nelson [email protected]
보낸 날짜: 2018년 5월 10일 목요일 오후 5:04:06
받는 사람: dotnet/corefx
참조: 아론 마이어스; 언급하다
제목: 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-% 2FAMuQLu5JGLcqrpMyGWLygbCsaSQSXFgNks5txNV2gaJpZM4E9KK- 인증 및 데이터 = 02퍼센트 7C01 % 7C % 7C0ef6d84125be4c450fdc08d5b6d2b70a % 7C84df9e7fe9f640afb435aaaaaaaaaaaa % 7C1 % 7C0 % 7C636615938478979295 및 SDATA = 9pnuMULuDu9HWb7un % 2FWYq6iYdjTKFsjN7nKiToaeHkk % 및 3D = 0 예약 .

IUnorderedSet 및 IOrderedSet 인터페이스를 추가하는 데 약간의 가치가 있을 수 있지만 IReadOnlySet 를 밀어서 탈선하는 것을 원하지 않습니다.

@pgolebiowski 의 제안이 마음에

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

그러면 간격(실수)과 같은 셀 수 없는 집합에도 적합합니다. 그와 IReadOnlySet 사이에서 ICountableSet (일명 IEnumerableSet ), IUnorderedSet 및 IOrderedSet 와 같은 몇 가지 다른 인터페이스에 잠재적으로 적합할 수 있습니다.

그러나 IReadOnlySet 있으면 현재 사용 가능한 것보다 크게 개선될 것이라는 데 동의합니다.

@NickRedwood의 경우 +1

오픈한지 3년이 넘었습니다. 접근 방식을 변경하여 이를 수행하십시오. @NickRedwood가 언급한 변경 사항을 소개하면 이 스레드에서 논의 중인 다른 모든 개선 사항이 허용됩니다. 모든 접근 방식은 이 사소한 일에 대해 동의합니다. 따라서 기본적인 이 간단한 사항을 추가한 다음 모두 선택 사항인 잠재적인 개선 사항에 대한 또 다른 문제를 생성해 보겠습니다.

@TylerBrinkley @safern @karelz @terrajobst

Contains 메서드만 있는 IReadOnlySet<T> 인터페이스에는 그다지 많은 이점이 없습니다. 이 방법은 유용하면서 이미에 포함 ICollection<T> 또한 갖는다 인터페이스 IsReadOnly 등록하는 단계의 변형 방식 여부를 지정하기위한 ICollection<T> 지원된다. ICollection<T> 구현하고 IsReadOnly return true . 지원할 것으로 예상되는 유일한 다른 기능은 열거 가능한 Count 속성과 너무 제한적으로 보이지 않는 CopyTo 메서드입니다.

제안된 IReadOnlySet<T> 가 IReadOnlyCollection<T> 기반으로 구현된다면 매우 기쁠 것입니다. 현재 사용 가능한 것에 대한 큰 개선이 될 것입니다. (@TylerBrinkley은 - 당신이 의미 가정 IReadOnlyCollection<T> 대신 ICollection<T> .

더 기본적인 인터페이스에 오류가 있는 것 같습니다. Set에 대한 인터페이스가 있다면 Contains 메소드가 있는 단일 메소드 인터페이스가 될 것입니다. 그것은 좋은 수학적 기초를 가지고 있으며 매우 깨끗합니다. 그러나 기존 클래스로 개조할 때는 개조를 덜 하는 것이 더 낫다는 것을 인정하며 인터페이스가 하나만 개조되어야 한다면 IReadOnlySet<T> 기반 IReadOnlyCollection<T> 이어야 합니다.

IReadOnlyCollection<> 에는 .Contains IReadOnlyCollection<> 가 없습니다. 공변이 되지 않기 때문입니다.

좋은 지적이며 이전 게시물을 반공변으로 수정했습니다. 스레드의 초기에 게시된 접근 방식이 사용되지 않는 한 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<> 가 없습니다. 왜냐하면 그렇게 하면 공변이 되지 않기 때문입니다.

이것이 지금 나에게 가장 큰 문제인 것 같다. 홀수 것 IReadOnlySet<T> 때 불변으로 IReadOnlyCollection<T> 공변입니다. 기존의 많은 IReadOnly* 인터페이스가 out T 로 신중하게 설계되었으며 쓰기 가능한 인터페이스는 반드시 불변인 것 같습니다. 우리 대부분은 IReadOnlySet<T> 가 최소한 Contains(T) 메서드를 선언하기를 원하지만 그렇게 하면 공변성을 방지할 수 있습니다.

ICollection 정말 Contains(T) 를 정의할 수 있는 올바른 위치라면 가능한가요? Collection<T> 및 HashSet<T> 의해 구현되고 불변인 IReadOnlyProbableCollection<T>.Contains(T) 일 수 있습니까?

@NickRedwood의 ISetCharacteristic<T> 제안이 더 깔끔해 보입니다. 심지어 유용할 수 있는 Count 를 구현하지 않아도 된다는 이점이 있습니다.

개인적으로 저는 IsReadOnly 속성의 팬이 아니므로 런타임 대신 컴파일 타임에 이 정보를 알고 싶습니다.

그 사람은 말을 잘하니 포도주를 더 부어 주십시오.

@binki IReadOnlyCollection<T> 가 포함되지 않았기 때문에 IReadOnlySet<T> 에 Contains 메서드가 있어야 한다는 데 동의하지만 다른 모든 비 돌연변이 ISet<T> 도 생각합니다

위에서 언급한 Dictionary.KeyCollection 사용 사례 외에 이 인터페이스를 추가하기 위해 어떤 다른 사용 사례를 생각해낼 수 있습니까?

좋습니다. API 디자인은 다음과 같습니다.

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

모두가 동의할 수 있는 디자인의 유일한 공통 부분입니다.

이제 여기서 디자인을 마치겠습니다. 앞으로 연장하고 싶다면 다른 호에서 하세요. 이것은 제품에 있어야 하는 가장 중요한 기능입니다.

누구를 위한 것인가, 누구를 반대하는 것인가?

@ashmind 의 제안이 마음에 듭니다 . Dictionary.Keys가 기술적으로 IReadOnlySet<TKey> 인 이 인터페이스를 구현할 수 있다면 정말 좋을 것입니다.

이것을 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 당신이 옳습니다. 변경할 수 없는 구현이 있으며 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>
읽기/쓰기 컬렉션이 읽기 전용 컬렉션의 확장이 되어서는 안 되는 이유는 무엇입니까?

@generik0

좋아요. 그러나 여전히 ICollection이 다음과 같이 표시되지 않아야 합니다.

ICollection<out T> : IReadOnlyCollection<out T>

읽기/쓰기 컬렉션이 읽기 전용 컬렉션의 확장이 되어서는 안 되는 이유는 무엇입니까?

먼저 ICollection<T> 에는 .Add(T item) 멤버가 있으므로 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가 있습니다: https://stackoverflow.com/a/14944400 .

@binki " " ICollection에 고정, 오타 지적해주셔서 감사합니다..
DotNetStandard 및 net461. 그리고 이것이 변화가 있어야 할 곳입니다. 넷스탠다드 2+

반복하겠습니다...
읽기/쓰기 컬렉션이 읽기 전용 컬렉션의 확장이 되어서는 안 되는 이유는 무엇입니까?

그리고 덜 노출시키기 위해 예를 들어 "ToArray()"로 컬렉션을 캐스팅해야 하는 이유는 무엇입니까?

그리고 문제를 일으키지 않고 상위 버전에 새 인터페이스를 추가할 수 있기 때문입니다. ICollection에는 이미 IReadOnlyCollection 메서드가 구현되어 있습니다. 주석은 깨져야 합니다... :-/

@generik0 당신이 생각하고 있는 소스 호환성을 깨뜨리지 않을 것 같습니다 [생각하지 않았습니다; 그럴 것이다], 하지만 C#이 아닌 IL 테이블에서 작동하는 바이너리 호환성을 깨뜨릴 것입니다.

좋아 @jnm2 감사합니다.
나는 이제 주제를 벗어난 호언장담을 중단할 것입니다. 단지 그것이 나쁜 아키텍처라고 생각하십시오. 들어주시고 설명해주셔서 감사합니다 :-)

@jnm2

@generik0 당신이 생각하는 소스 호환성을 깨뜨리지 않는 것처럼 보이지만 C#이 아닌 IL 테이블에서 작동하는 바이너리 호환성을 깨뜨릴 것입니다.

(죄송합니다.) 소스가 .net-4.5 이전 버전에서 명시적으로 ICollection<T> 를 구현한 경우 소스 호환성도 깨집니다. IReadOnlyCollection<T>.Count 를 명시적으로 구현하지 못해 클래스가 컴파일되지 않기 시작합니다. 그러나 바이너리 호환성은 광범위한 .net 버전을 대상으로 하는 것을 방지하기 때문에 더 큰 문제입니다. 이전 프레임워크를 대상으로 하는 대신 둘 다 대상으로 지정해야 함).

ICollection<T> 가 .NET Core 3.0+에 대해 IReadOnlyCollection<T> 를 구현할 수 있는지 C#8에 기본 인터페이스 구현 지원이 추가되었는지 궁금합니다.

확장이 필요할 수도 있고 최소한 동일한 컬렉션일 수도 있습니다. ienumerable 또는 icollection을 reaadonlycollection으로 가져와야 하는 경우 ... 어떤 생각이 있으십니까?

[ @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"); } }

@generik0 해당 메서드를 호출하는 대신 enumerable as IReadOnlyCollection<T> ?? throw ... 또는 (IReadOnlyCollection<T>)enumerable 를 사용하지 않는 이유는 무엇입니까?

@jnm2 옴 . 당신이 맞습니다. 가끔은 명료한 그림이 안 보이고 너무 복잡해지는 경우가 있습니다!!!

나는 단순함을 얻기 위해 여전히 확장을 호출 할 것입니다 ;-)
고마워 친구....

여기 상태가 어떻습니까? 나는 표준 lib에서 이 인터페이스를 정말 원하고 HashSet<>가 그것을 구현하도록 합니다.

Shapes 제안이 (잘하면) 구현될 때까지 잠시 더 기다리는 것이 최선의 방법인 것 같습니다. 그런 다음 원하는 세트 유형을 나타내는 모양 그룹을 만들고 HashSet<T> 와 같은 기존 세트가 이를 준수하도록 구현을 제공할 수 있습니다.

정확히 이것을 수행하는 커뮤니티 라이브러리가 등장할 수 있으며, 다양한 유형의 집합(내포(술어) 및 확장(나열됨), 정렬, 부분 정렬, 정렬되지 않음, 셀 수 있음, 셀 수 있는 무한, 셀 수 없는 무한, 가능하게는 Rational과 같은 수학적 도메인 포함)을 모두 포함합니다. , 자연수 등) 이러한 집합에 대해 정의된 모든 합집합, 교집합, 카디널리티 방법을 사용하여 다른 모양으로 사용할 수 있습니다.

그것은 나에게 5년 후처럼 들린다. 하루 만에 구현할 수 있는 간단한 변경이 일어나지도 않은 1000배 더 큰 아직 지정되지 않은 기능을 기다려야 하는 이유는 무엇입니까?

그것은 나에게 5년 후처럼 들린다. 하루 만에 구현할 수 있는 간단한 변경이 일어나지도 않은 1000배 더 큰 아직 지정되지 않은 기능을 기다려야 하는 이유는 무엇입니까?

나는 단지 IReadOnlySet<T> 에 대한 진전이 없는 것에 응답하고 있습니다 - 이 문제는 이미 4년 후에 공개되었습니다.

마이크로소프트 방식: 가장 간단하고 유용한 것은 수십 년이 걸립니다. 정신이 번쩍 든다. 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에 인터페이스를 추가했습니다.

마지막 질문 Dan, 이것을 위해 Mono를 변경해야 합니까? corefx가 끝나고 모노가 시작되는 위치에 대해 통찰력이 없습니다. 그래서 만약 당신이 그것이 나를 독립적인 연구로부터 구할 수 있다는 것을 안다면

@Jlalond Mono를 변경할 필요가 없습니다. Mono 런타임을 이 리포지토리로 이동하는 이유 중 하나는 CoreCLR 또는 Mono 런타임과 동일한 정확한 라이브러리를 원활하게 사용하기 위함입니다. 핵심 라이브러리에서 다음과 같이 작은 부분만 다릅니다.
coreclrsrcSystem.Private.CoreLib 대 mononetcoreSystem.Private.CoreLib. (대부분의 핵심 라이브러리는 librarySystem.Private.CoreLib 외부에서 공유됩니다). 그래서 당신이 그것을 만지지 않는 한 - 당신은 영향을 받지 않습니다.

@danmosemsft 설명

이봐 @danmosemsft 는 이것에 대해 후속 조치를

주소 #32488