Remove section for deemphasizing existentials.

proposals/NNNN-unlock-existential-types-for-all-protocols.md

@@ -310,72 +310,6 @@ The current semantics regarding existential types prevent language users, especi
 
 ## Future Directions
 
-### Deemphasize Existential Types Through Diagnostics and Literature 
-
-It is often that people reach for existential types when they should be employing generic contraints — "should" not merely for performance reasons, but because they truly do not need or intend for any type erasure. Even though the compiler is sometimes able to back us up performance-wise by turning existential code into generic code (as in  `func foo(s: Sequence)` vs `func foo<S: Sequence>(s: S)`), there is an important difference between the two abstractions. Existential types provide value-level abstraction, that is, they eliminate the type-level distinction between different values of the type, and cannot maintain type relationships between independent existential values. Under most cirumstances, value-level abstraction only really makes sense in mutable state, in the elements of heterogeneous containers, or within larger type-erasing constructs — *unless* our support of [`some` types](https://github.com/apple/swift-evolution/blob/main/proposals/0244-opaque-result-types.md) can turn the tide.
-
-The language documentation may play a crucial role in deemphasizing value-level abstraction early on. Namely, when one goes to the swift documentation site, under the protocols section, they’ll be greeted with a subsection called "[Protocols as Types](https://docs.swift.org/swift-book/LanguageGuide/Protocols.html#ID275)", which contains this example:
-
-```swift
-class Dice {
-
-  let sides: Int
-
-  let generator: RandomNumberGenerator
-  // Here, ‘generator’ is bound to the existential
-  // type of ‘RandomNumberGenerator’
-
-
-  init(sides: Int, generator: RandomNumberGenerator) {
-    self.sides = sides
-    self.generator = generator 
-  }
-
-
-  func roll() -> Int {
-    return Int(generator.random() * Double(sides)) + 1
-  }
-
-}
-```
-
-The authors of this section are not to blame for the inappropriate use of an existential type, as this section was written before [opaque types]() where introduced. However, now it seems that documentation and diagnostics can be improved to mitigate this problem. Therefore, we could encourage the use of opaque result types: 
-
-```swift
-let randomNumberGenerator: some  RandomNumberGenerator = …
-```
-
-Or offer different diagnostics for the following code:
-
-```swift
-struct Dice {
-
-  let generator: some RandomNumberGenerator ❌
-  // Error: Property declares an opaque return type,
-  // but has no initializer expression from which to infer
-  // an underlying type.
-
-  init(sides: Int, generator: some RandomNumberGenerator) { ❌
-    // Error: 'some' types are only implemented for the declared 
-    // type of properties and subscripts and the return type of functions
-
-    self.sides = sides
-    self.generator = generator 
-  }
-
-  …
-
-} 
-```
-
-Maybe, we could provide a fix-it message that prompts us to use generics:
-
-> Did you mean to use a generic parameter conforming to `RandomNumberGenerator` in struct `Dice`?
-
-As for the second case, such syntax could be made valid in a future proposal, as it is quite unambiguous and could be equivalent to `<NumberGenerator : RandomNumberGenerator>`.
-
-Lastly, the overall documentation could use existential types only when appropriate and note that it's different from generics.
-
 ### Simplify the Implementation of Type-Erasing Wrappers
 
 Currently, in the standard library there's a custom existential type for `Hashable`, which is called [`AnyHashable`](https://developer.apple.com/documentation/swift/anyhashable). The current implementation of `AnyHashable` is quite complex and unintuitive. However, with the proposed change it could be simplfied and from 306 to 237 lines of code, while having a much simpler mental medal. The important thing to note about `AnyHashable` is that it conforms to the protocol it is an existential of: `Hashable`, which is something that the compiler can't automatically provide. Furthermore, `Equatable` has `Self` requirements in non-covariant positions, which means that such requirements are inaccessible through the existential type. To combat the last limitation, an internal extension to `Equatable` could be added: