David Abrahams <[EMAIL PROTECTED]> wrote: > Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: > >> IMO we should just stop using 'void_' for internal purposes and give it >> up to users :). > > I am still unsure about 'void_' being better than 'nil' or > 'null'.... Users already have a type, 'void', which means void. > There's no correspondence between void_ and void the way there is > between bool_ and bool.
IMO, there is. For example, the new TR1 tuples implementation (it's feature complete and in the sandbox now BTW) uses void_ as it would a void tuple element. nil_t or something would do, but we'll need to convert this to void_ simply because MPL expects void_. Admittedly, the void_ is not part of its public API and the use should not care about it, *but* you have to consider that the tuple lib *IS* a client of MPL. As such, it needs the mpl_void_ as a *public* API. Another good example is Phoenix/LL. We are using void_ much as a void argument to something. Here now, there is a direct mapping to our C++ void. Again, the void_ is not part of Phoenix's public API but then again, it *is* a client of MPL. -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
