1[/
2    Boost.Optional
3
4    Copyright (c) 2003-2007 Fernando Luis Cacciola Carballal
5
6    Distributed under the Boost Software License, Version 1.0.
7    (See accompanying file LICENSE_1_0.txt or copy at
8    http://www.boost.org/LICENSE_1_0.txt)
9]
10
11
12[section:acknowledgements Acknowledgements]
13
14[heading Pre-formal review]
15
16* Peter Dimov suggested the name 'optional', and was the first to point out
17the need for aligned storage.
18* Douglas Gregor developed 'type_with_alignment', and later Eric Friedman
19coded 'aligned_storage', which are the core of the optional class
20implementation.
21* Andrei Alexandrescu and Brian Parker also worked with aligned storage
22techniques and their work influenced the current implementation.
23* Gennadiy Rozental made extensive and important comments which shaped the
24design.
25* Vesa Karvonen and Douglas Gregor made quite useful comparisons between
26optional, variant and any; and made other relevant comments.
27* Douglas Gregor and Peter Dimov commented on comparisons and evaluation
28in boolean contexts.
29* Eric Friedman helped understand the issues involved with aligned storage,
30move/copy operations and exception safety.
31* Many others have participated with useful comments: Aleksey Gurotov,
32Kevlin Henney, David Abrahams, and others I can't recall.
33
34[heading Post-formal review]
35
36* William Kempf carefully considered the originally proposed interface
37and suggested the new interface which is currently used. He also started and
38fueled the discussion about the analogy optional<>/smart pointer and about
39relational operators.
40* Peter Dimov, Joel de Guzman, David Abrahams, Tanton Gibbs and Ian Hanson
41focused on the relational semantics of optional (originally undefined);
42concluding with the fact that the pointer-like interface doesn't make it a
43pointer so it shall have deep relational operators.
44* Augustus Saunders also explored the different relational semantics between
45optional<> and a pointer and developed the OptionalPointee concept as an aid
46against potential conflicts on generic code.
47* Joel de Guzman noticed that optional<> can be seen as an API on top of
48variant<T,nil_t>.
49* Dave Gomboc explained the meaning and usage of the Haskell analog to
50optional<>: the Maybe type constructor (analogy originally pointed out by
51David Sankel).
52* Other comments were posted by Vincent Finn, Anthony Williams, Ed Brey,
53Rob Stewart, and others.
54* Joel de Guzman made the case for the support of references and helped
55with the proper semantics.
56* Mat Marcus shown the virtues of a value-oriented interface, influencing
57the current design, and contributed the idea of "none".
58* Vladimir Batov's design of Boost.Convert library motivated the development
59of value accessors for `optional`: functions `value`, `value_or`, `value_or_eval`.
60
61[endsect]
62
63