ceph/src/boost/libs/optional/doc/92_acknowledgments.qbk

   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
  17 the need for aligned storage.
  18 * Douglas Gregor developed 'type_with_alignment', and later Eric Friedman
  19 coded 'aligned_storage', which are the core of the optional class
  20 implementation.
  21 * Andrei Alexandrescu and Brian Parker also worked with aligned storage
  22 techniques and their work influenced the current implementation.
  23 * Gennadiy Rozental made extensive and important comments which shaped the
  24 design.
  25 * Vesa Karvonen and Douglas Gregor made quite useful comparisons between
  26 optional, variant and any; and made other relevant comments.
  27 * Douglas Gregor and Peter Dimov commented on comparisons and evaluation
  28 in boolean contexts.
  29 * Eric Friedman helped understand the issues involved with aligned storage,
  30 move/copy operations and exception safety.
  31 * Many others have participated with useful comments: Aleksey Gurotov,
  32 Kevlin 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
  37 and suggested the new interface which is currently used. He also started and
  38 fueled the discussion about the analogy optional<>/smart pointer and about
  39 relational operators.
  40 * Peter Dimov, Joel de Guzman, David Abrahams, Tanton Gibbs and Ian Hanson
  41 focused on the relational semantics of optional (originally undefined);
  42 concluding with the fact that the pointer-like interface doesn't make it a
  43 pointer so it shall have deep relational operators.
  44 * Augustus Saunders also explored the different relational semantics between
  45 optional<> and a pointer and developed the OptionalPointee concept as an aid
  46 against potential conflicts on generic code.
  47 * Joel de Guzman noticed that optional<> can be seen as an API on top of
  48 variant<T,nil_t>.
  49 * Dave Gomboc explained the meaning and usage of the Haskell analog to
  50 optional<>: the Maybe type constructor (analogy originally pointed out by
  51 David Sankel).
  52 * Other comments were posted by Vincent Finn, Anthony Williams, Ed Brey,
  53 Rob Stewart, and others.
  54 * Joel de Guzman made the case for the support of references and helped
  55 with the proper semantics.
  56 * Mat Marcus shown the virtues of a value-oriented interface, influencing
  57 the current design, and contributed the idea of "none".
  58 * Vladimir Batov's design of Boost.Convert library motivated the development
  59 of value accessors for `optional`: functions `value`, `value_or`, `value_or_eval`.
  60
  61 [endsect]
  62