Merge pull request #935 from EZ-NET/correct_document_set-type-parameter-name

[stdlib] [docs] Modify Set's type parameter name in comments.

Author: gribozavr

docs/proposals/Inplace.rst

@@ -23,30 +23,30 @@ In recent standard library design meetings about the proper API for
 sets, it was decided that the canonical ``Set`` interface should be
 written in terms of methods: [#operators]_ ::
 
-  struct Set<T> {
-    public func contains(x: T) -> Bool                // x ∈ A, A ∋ x
-    public func isSubsetOf(b: Set<T>) -> Bool         // A ⊆ B
-    public func isStrictSubsetOf(b: Set<T>) -> Bool   // A ⊂ B
-    public func isSupersetOf(b: Set<T>) -> Bool       // A ⊇ B
-    public func isStrictSupersetOf(b: Set<T>) -> Bool // A ⊃ B
+  struct Set<Element> {
+    public func contains(x: Element) -> Bool                // x ∈ A, A ∋ x
+    public func isSubsetOf(b: Set<Element>) -> Bool         // A ⊆ B
+    public func isStrictSubsetOf(b: Set<Element>) -> Bool   // A ⊂ B
+    public func isSupersetOf(b: Set<Element>) -> Bool       // A ⊇ B
+    public func isStrictSupersetOf(b: Set<Element>) -> Bool // A ⊃ B
     ...
   }
 
 When we started to look at the specifics, however, we ran into a
 familiar pattern::
    
   ...
-    public func union(b: Set<T>) -> Set<T>              // A ∪ B
-    public mutating func unionInPlace(b: Set<T>)        // A ∪= B
+    public func union(b: Set<Element>) -> Set<Element>        // A ∪ B
+    public mutating func unionInPlace(b: Set<Element>)        // A ∪= B
 
-    public func intersect(b: Set<T>) -> Set<T>          // A ∩ B
-    public mutating func intersectInPlace(b: Set<T>)    // A ∩= B
+    public func intersect(b: Set<Element>) -> Set<Element>    // A ∩ B
+    public mutating func intersectInPlace(b: Set<Element>)    // A ∩= B
 
-    public func subtract(b: Set<T>) -> Set<T>           // A - B
-    public mutating func subtractInPlace(b: Set<T>)     // A -= B
+    public func subtract(b: Set<Element>) -> Set<Element>     // A - B
+    public mutating func subtractInPlace(b: Set<Element>)     // A -= B
 
-    public func exclusiveOr(b: Set<T>) -> Set<T>        // A ⊕ B
-    public mutating func exclusiveOrInPlace(b: Set<T>)  // A ⊕= B
+    public func exclusiveOr(b: Set<Element>) -> Set<Element>  // A ⊕ B
+    public mutating func exclusiveOrInPlace(b: Set<Element>)  // A ⊕= B
 
 We had seen the same pattern when considering the API for
 ``String``, but in that case, there are no obvious operator

stdlib/public/SDK/Foundation/Foundation.swift

@@ -859,7 +859,7 @@ public func _convertNSSetToSet<T : Hashable>(s: NSSet?) -> Set<T> {
   return result!
 }
 
-// Set<T> is conditionally bridged to NSSet
+// Set<Element> is conditionally bridged to NSSet
 extension Set : _ObjectiveCBridgeable {
   public static func _getObjectiveCType() -> Any.Type {
     return NSSet.self

stdlib/public/core/SetAlgebra.swift

@@ -22,7 +22,7 @@
 ///
 /// > `a` **subsumes** `b` iff `([a] as Self).isSupersetOf([b])`
 ///
-/// In many models of `SetAlgebraType` such as `Set<T>`, `a`
+/// In many models of `SetAlgebraType` such as `Set<Element>`, `a`
 /// *subsumes* `b` if and only if `a == b`, but that is not always the
 /// case.  For example, option sets typically do not satisfy that
 /// property.