(На ваш первоначальный вопрос о set был дан ответ. IIRC, «набор» - это слово с самыми разными значениями в английском языке ... очевидно, это также влияет на вычисления.)

Я думаю, что это нормально иметь HashSet<T> с таким именем, но я бы определенно приветствовал интерфейс ISet<T>. Учитывая, что HashSet<T> появился только в .NET 3.5 (что само по себе было неожиданно), я подозреваю, что в конечном итоге мы можем получить более полную коллекцию основанных на множестве типов. В частности, в некоторых случаях будет полезен эквивалент LinkedHashSet в Java, который поддерживает порядок вставки.

Честно говоря, интерфейс ICollection<T> на самом деле покрывает большую часть того, что вы хотели бы видеть в ISet<T>, так что, возможно, это и не требуется. Однако вы могли бы возразить, что основная цель набора (которая в основном связана с сдерживанием и только косвенно с возможностью перебора элементов) не совсем то же самое, что и коллекция. Это сложно. На самом деле истинно математический набор может не быть повторяемым или счетным — например, у вас может быть «набор действительных чисел от 1 до 2». Если бы у вас был числовой тип произвольной точности, счет был бы бесконечным, и повторение его не имело бы никакого смысла.

Точно так же идея «добавления» к набору не всегда имеет смысл. Изменчивость - сложная задача при именовании коллекций :(

РЕДАКТИРОВАТЬ: Хорошо, отвечая на комментарий: ключевое слово set никоим образом не является наследием Visual Basic. Это операция, которая устанавливает значение свойства, а get извлекает операцию. Это не имеет ничего общего с идеей множества как операции.

Представьте, что вместо этого ключевые слова на самом деле были fetch и assign, например.

// Not real code!
public int Foo
{
    fetch
    {
        return fooField;
    } 
    assign
    {
        fooField = value;
    } 
}

Там цель ясна? Теперь реальный эквивалент этого в C# просто

public int Foo
{
    get
    {
        return fooField;
    } 
    set
    {
        fooField = value;
    } 
}

Итак, если вы пишете:

x = y.Foo;

который будет использовать get часть свойства. Если вы пишете:

y.Foo = x;

который будет использовать часть set.

Так понятнее?

Набора<T> нет. Этот сообщение в блоге команды BCL содержит много подробностей о HashSet, включая не совсем убедительное обсуждение включения хэша в имя. Я подозреваю, что не всем в команде BCL понравилось решение использовать имя HashSet<T>.

Единственной причиной этого кажется отсутствие ресурсов для идеальной реализации этого в .NET 3.5.

.NET 4.0 будет включать ISet, а также его новая реализация в дополнение к HashSet - SortedSet. Ознакомьтесь с предоставленными ссылками на библиотеку MSDN — они уже доступны в .NET 4.0 beta1.

set — это ключевое слово языка C#, которое используется с версии 1.0. Is используется для определения части свойства, присваивающей значение (а get используется для реализации части свойства, считывающей значение). В этом контексте вы должны понимать слово «установить» как глагол, как при установке значения.

HashSet<T> — это конкретная реализация математической концепции множества. Впервые он был представлен в .NET 3.5. Этот пост в блоге команды BCL объясняет больше причин, лежащих в его основе, а также некоторые подсказки, почему имя HashSet<T>, а не просто Set<T>: http://blogs.msdn.com/bclteam/archive/2006/11/09/introduction-hashset-t-kim-hamilton.aspx.

В случае HashSet<T> вы должны понимать слово "набор" как существительное.

Set — зарезервированное ключевое слово в VB.NET (эквивалентно set в C#). VB.NET может использовать классы/методы/и т. д. с тем же именем, что и ключевые слова, но они должны быть написаны между квадратными скобками, что некрасиво:

Imports Wintellect.PowerCollections 'PowerCollections contains a class called Set'
Public Class Test
    Private _myValue As Integer  

    Public Property MyValue() As Integer
        Get
            Return _myValue
        End Get
        Set ' Set as keyword'
            _myValue = value
        End Set
    End Property

    Public Function X As [Set](Of Integer)
        Dim a As New [Set](Of Integer) ' Set as class'
        Return a
    End Function

End Class

А, теперь я понял ваш вопрос
Не уверен, что могу на 100% увидеть необходимость в ISet<T>.
Думаю, вопрос в том, какое поведение вы считаете важным для набора?
Так ли это? Добавить, Удалить, Содержит и т. д. Если это так, то ICollection<T> уже предоставляет для этого интерфейс.
Если это такие операции над наборами, как объединение, пересечение и т. д., то это то, что вы считаете достаточно общим, чтобы абстрагироваться от стиля контракта. правоприменение?

Я должен сказать, что не знаю правильного ответа на этот вопрос - я думаю, что он открыт для обсуждения, и я подозреваю, что команда BCL может в конечном итоге добавить что-то подобное в будущую версию, но это зависит от них. Лично я не считаю это огромной недостающей частью функциональности.

Исходное сообщение

В BCL вообще нет коллекции Set, по крайней мере, насколько мне известно.
Существует несколько сторонних библиотек Set, таких как Iesi.Collections
HashSet<T> был введен в .NET 3.5 для создания коллекции быстрого набора, т. е. там, где вам нужна коллекция без дубликатов. Он также имеет типичные операции с множествами, такие как объединение и соединение. Просмотрите эту ссылку от команды BCL на HashSet

Обычно вы использовали его там, где раньше вам приходилось использовать List<T> и проверять наличие дубликатов при добавлении.
Добавление элементов в HashSet<T> также может быть значительно быстрее, чем список

Некоторые дополнительные подробности:
Еще одна приятная особенность HashSet заключается в том, что он не генерирует исключение, если вы пытаетесь добавить дубликат, он просто не добавляет повторяющуюся запись, что избавляет вас от необходимости размещать множество блоков try.catch. каждое добавление - приятно :)

Я почти уверен, что в BCL нет класса Set<T>, по крайней мере, в .NET 3.5 (и, похоже, не в .NET 4.0). В любом случае, что вы ожидаете от такого класса?

HashSet<T> сама по себе является обычной структурой набора данных, которая использует хеш-коды (метод GetHashCode объекта) для сравнения элементов. Это просто эффективный способ реализации заданного типа. (Другие методы проверки равенства, вероятно, будут иметь более низкую производительность.)