David Abrahams wrote: > Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: > >> David Abrahams 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. >> >> ... in conventional run-time programs. Unfortunately, 'void' is not >> special for metaprograms, many of which have a need to routinely >> manipulate it along with all other built-in types. 'mpl::void_' >> addresses this issue. >> >>> There's no correspondence between void_ and void the way there is >>> between bool_ and bool. >> >> 'void_' in MPL plays a role very similar to a role of 'void' in the >> core language. So, conceptually, there is a correspondence. > > But that's only true as long as void_ is being used for internal > purposes. Once you "give it up to users" as you suggest, it loses > that correspondence, and we'll have some other internal name which > has that correspondence to void.
Maybe the problems are caused by overloading void_. I haven't looked at MPL recently, but as a general observation I have identified at least three uses of a void_-like entity. 1. A type parameter used to emulate a variable argument template. I use '_missing' for this purpose (leading underscore for implementation details.) template<class A1 = _missing, class A2 = _missing, ...> struct F; 2. An optional parameter that, when not supplied, has a reasonable (dependent) default. I use 'unspecified'. template<class R = unspecified, class F> ... bind(F f); 3. A type that is guaranteed to be distinct from all other useful types. 'nil' is what Lisp calls it; void_ is fine, too. HTH :-) _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost