[SE-0095] Converted the docs to new composition syntax

Author: joewillsher

CHANGELOG.md

@@ -4,7 +4,8 @@ Swift 3.0
 ---------
 
 * [SE-0095](https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md):
-The `protocol<...>` composition construct has been removed. In its place, an infix type operator `&` has been introduced.
+The `protocol<...>` composition construct has been removed. In its
+place, an infix type operator `&` has been introduced.
 
 ```swift
 let a: Foo & Bar
@@ -14,7 +15,9 @@ func bar(x: Foo & Bar) { … }
 typealias G = GenericStruct<Foo & Bar>
 ```
 
-The empty protocol composition, the `Any` type, was previously defined as being `protocol<>`. This has been removed from the standard library and `Any` is now a keyword with the same behaviour.
+The empty protocol composition, the `Any` type, was previously 
+defined as being `protocol<>`. This has been removed from the 
+standard library and `Any` is now a keyword with the same behaviour.
 
 * [SE-0091](https://github.com/apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-protocols.md):
   Operators can now be defined within types or extensions thereof. For example:

docs/ABI.rst

@@ -259,9 +259,9 @@ enum in declaration order.
 Existential Container Layout
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Values of protocol type, protocol composition type, or "any" type
-(``protocol<>``) are laid out using **existential containers** (so-called
-because these types are "existential types" in type theory). 
+Values of protocol type, protocol composition type, or ``Any`` type are laid
+out using **existential containers** (so-called because these types are
+"existential types" in type theory).
 
 Opaque Existential Containers
 `````````````````````````````
@@ -346,8 +346,7 @@ All metadata records share a common header, with the following fields:
   * `Tuple metadata`_ has a kind of **9**.
   * `Function metadata`_ has a kind of **10**.
   * `Protocol metadata`_ has a kind of **12**. This is used for
-    protocol types, for protocol compositions, and for the "any" type
-    ``protocol<>``.
+    protocol types, for protocol compositions, and for the ``Any`` type.
   * `Metatype metadata`_ has a kind of **13**.
   * `Class metadata`_, instead of a kind, has an *isa pointer* in its kind slot,
     pointing to the class's metaclass record. This isa pointer is guaranteed
@@ -462,9 +461,9 @@ contain the following fields:
   `protocol descriptor`_ records, but are pre-calculated for convenience.
 
 - The **number of protocols** that make up the protocol composition is stored at
-  **offset 2**. For the "any" types ``protocol<>`` or ``protocol<class>``, this
+  **offset 2**. For the "any" types ``Any`` or ``Any : Class``, this
   is zero. For a single-protocol type ``P``, this is one. For a protocol
-  composition type ``protocol<P, Q, ...>``, this is the number of protocols.
+  composition type ``P & Q & ...``, this is the number of protocols.
 
 - The **protocol descriptor vector** begins at **offset 3**. This is an inline
   array of pointers to the `protocol descriptor`_ for every protocol in the
@@ -564,7 +563,7 @@ for ``T``, ``U``, and ``V`` in succession, as if laid out in a C struct::
   };
 
 If we add protocol requirements to the parameters, for example,
-``<T: Runcible, U: protocol<Fungible, Ansible>, V>``, then the type's generic
+``<T: Runcible, U: Fungible & Ansible, V>``, then the type's generic
 parameter vector contains witness tables for those protocols, as if laid out::
 
   struct GenericParameterVector {

docs/Generics.rst

@@ -473,20 +473,17 @@ create a new protocol aggregating those protocols::
 
 However, this only makes sense when the resulting protocol is a useful
 abstraction. A SerializableDocument may or may not be a useful abstraction. When
-it is not useful, one can instead use protocol<> types to compose different
-protocols, e.g.,::
+it is not useful, one can instead use '&' types to compose different protocols, e.g.,::
 
-  var doc : protocol<Document, Serializable>
+  var doc : Document & Serializable
 
 Here, doc has an existential type that is known to conform to both the Document
 and Serializable protocols. This gives rise to a natural "top" type, such that
 every type in the language is a subtype of "top". Java has java.lang.Object, C#
 has object, Objective-C has "id" (although "id" is weird, because it is also
 convertible to everything; it's best not to use it as a model). In Swift, the
-"top" type is simply an empty protocol composition::
+"top" type is simply an empty protocol composition: ``Any``::
 
-  typealias Any = protocol<>
-  
   var value : Any = 17 // an any can hold an integer
   value = "hello" // or a String
   value = (42, "hello", Red) // or anything else
@@ -858,9 +855,9 @@ is effectively parsed as::
 
 by splitting the '>>' operator token into two '>' operator tokens.
 
-However, this is manageable, and is already implemented for protocol composition
-(protocol<>). The larger problem occurs at expression context, where the parser
-cannot disambiguate the tokens::
+However, this is manageable, and is already implemented for the (now depreacted)
+protocol composition syntax (protocol<>). The larger problem occurs at expression
+context, where the parser cannot disambiguate the tokens::
 
   Matrix<Double>(10, 10)
 

docs/TypeChecker.rst

@@ -608,7 +608,7 @@ types formed by the conversion relationship, e.g., there is an edge
 ``A -> B`` in the latter if ``A`` is convertible to ``B``. ``B`` would
 therefore be higher in the lattice than ``A``, and the topmost element
 of the lattice is the element to which all types can be converted,
-``protocol<>`` (often called "top"). 
+``Any`` (often called "top").
 
 The concrete types "above" and "below" a given type variable provide
 bounds on the possible concrete types that can be assigned to that

docs/archive/LangRef.html

@@ -1324,16 +1324,14 @@ <h3 id="type-optional">Optional Types</h3>
   <!-- _____________________________________________________________________ -->
   <h3 id="type-composition">Protocol Composition Types</h3>
   <pre class="grammar">
-   type-composition ::= 'protocol' '&lt;' type-composition-list? '&gt;'
-
-   type-composition-list ::= <a href="#type-identifier">type-identifier</a> (',' <a href="#type-identifier">type-identifier</a>)*
+   type-composition ::= <a href="#type-identifier">type-identifier</a> ('&amp;' <a href="#type-identifier">type-identifier</a>)*
   </pre>
 
   <p>A protocol composition type composes together a number of
   protocols to describe a type that meets the requirements of each of
-  those protocols. A protocol composition type <code>protocol&lt;A,
-  B&gt;</code> is similar to an explicitly-defined protocol that
-  inherits both <code>A</code> and <code>B</code></p>
+  those protocols. A protocol composition type <code>A &amp; B</code>
+  is similar to an explicitly-defined protocol that inherits both
+  <code>A</code> and <code>B</code></p>
 
 <pre class="example">
 protocol C : A, B { }
@@ -1348,18 +1346,17 @@ <h3 id="type-composition">Protocol Composition Types</h3>
     conform to that name.
   </div>
 
-  <p>Each of the types named in the
-  <code>type-composition-list</code> shall refer to either a protocol
-  or to a protocol composition. The list may be empty, in which case
-  every type conforms to the empty protocol composition. This is how
-  the <code>Any</code> type is defined in the standard library.</p>
+  <p>Each of the types named in the <code>type-composition</code> shall
+  refer to either a protocol or to a protocol composition. The empty
+  protocol composition is the keyword <code>Any</code> and every
+  type conforms to it.
 
  <pre class="example">
     <i>// A value that represents any type</i>
-    var any : protocol&lt;&gt; = 17
+    var any : Any = 17
 
     <i>// A value that conforms to both the Document and Enumerator protocols</i>
-    var doc : protocol&lt;Document,Enumerator&gt;
+    var doc : Document &amp; Enumerator
     doc.isEmpty()       <i>// uses Enumerator.isEmpty()</i>
     doc.title = "Hello" <i>// uses Document.title</i>
 </pre>