|
Boost : |
From: Peter Dimov (pdimov_at_[hidden])
Date: 2003-07-13 07:49:51
David Abrahams wrote:
> Aleksey Gurtovoy <agurtovoy_at_[hidden]> writes:
>
>> David Abrahams wrote:
>>> Aleksey Gurtovoy <agurtovoy_at_[hidden]> 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 :-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk