Copy-editing optional documentation. Fixes #5382 and a few other issues I noticed while I was at it.

[SVN r71052]

Conflicts:
	doc/html/boost_optional/detailed_semantics.html
	doc/html/index.html

doc/development.qbk

@@ -1,4 +1,4 @@
-[/
+[/
     Boost.Optional
 
     Copyright (c) 2003-2007 Fernando Luis Cacciola Carballal
@@ -58,7 +58,7 @@ The observation made in the last paragraph about the irrelevant nature of the
 additional `nil_t` with respect to [_purpose] of `optional<T>` suggests an 
 alternative model: a ['container] that either has a value of `T` or nothing.
 
-As of this writing I don't know of any precedence for a variable-size
+As of this writing I don't know of any precedent for a variable-size
 fixed-capacity (of 1) stack-based container model for optional values, yet I
 believe this is the consequence of the lack of practical implementations of
 such a container rather than an inherent shortcoming of the container model.
@@ -176,14 +176,14 @@ untitialized optional objects: The operators * and ->]
 A relevant feature of a pointer is that it can have a [*null pointer value].
 This is a ['special] value which is used to indicate that the pointer is not
 referring to any object at all. In other words, null pointer values convey
-the notion of inexistent objects.
+the notion of nonexistent objects.
 
 This meaning of the null pointer value allowed pointers to became a ['de
 facto] standard for handling optional objects because all you have to do
 to refer to a value which you don't really have is to use a null pointer
 value of the appropriate type. Pointers have been used for decades—from
 the days of C APIs to modern C++ libraries—to ['refer] to optional (that is,
-possibly inexistent) objects; particularly as optional arguments to a
+possibly nonexistent) objects; particularly as optional arguments to a
 function, but also quite often as optional data members.
 
 The possible presence of a null pointer value makes the operations that

doc/optional.qbk

@@ -99,7 +99,7 @@ functions could have the following interface:
     std::pair<char,bool> get_async_input();
     std::pair<point,bool> polygon::get_any_point_effectively_inside();
 
-These functions use a consistent interface for dealing with possibly inexistent
+These functions use a consistent interface for dealing with possibly nonexistent
 results:
 
     std::pair<point,bool> p = poly.get_any_point_effectively_inside();

doc/reference.qbk

@@ -234,7 +234,7 @@ __SPACE__
 
 * otherwise, same as:
 
-[: `optional<T ['(not a ref)]>::optional()`]
+[: `optional<T `['(not a ref)]`>::optional()`]
 [: `optional<T&>           ::optional()`]
 
 __SPACE__
@@ -515,7 +515,7 @@ from the factory `f` (i.e., the value [_is not copied]).
 * [*Notes:] See [link boost_optional.in_place_factories In-Place Factories]
 * [*Exception Safety:] Exceptions can only be thrown during the call to
 the `T` constructor used by the factory; in that case, the `optional` object
-will be left empty.
+will be reset to be ['uninitialized].
 
 __SPACE__