Aleksey Gurtovoy <[EMAIL PROTECTED]> wrote: > 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. Personally, I > appreciate the analogy, dislike 'null'/'nil'/etc. for the lack of such, and > would like to keep the name.
I agree. I used to use nil_t but since I bumped into MPL's void_, I wouldn't want to use nil_t anymore. void_ simply makes sense. My dictionary defines void as: 1) The state of nonexistence 2) An empty area or space, and nul/null as: 1) Nothing 2) A quantity of no importance. IMO, the definition of void reflects mpl::void_ a lot more. -- 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
