92_acknowledgments.qbk 2.7 KB

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