[boost] Re: mpl/loki

From: Daniel Frey (daniel.frey_at_[hidden])
Date: 2003-07-14 03:25:40

Peter Dimov wrote:
> David Abrahams wrote:
> 
>>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.

 From my experience it's a bad idea to have one general, user-documented 
type that is used as a default for variable argument templates. The 
problem is that when a user knows the type's name and thus the type (be 
it called void_, nan or whatever), he might also expect to be able to 
work with it like with any other type. If forming a container-type 
(mpl::vector, ...), it should be possible to inject the type like all 
other types because otherwise, well, it wouldn't be a type and the user 
will be surprised no matter whether you document it or not.

I therefore think that each library should have an internal type that 
the user doesn't know about and that might then be put it into a 
namespace detail or something and called depending on it's semantics. 
Makes it easier to understand the type's role inside the library, thus 
increases readability and maintainability and improved orthogonality of 
different libraries.

Also, I wonder what reasons are there to create a general type for this 
purpose. Avoiding code duplication doesn't sound reasonable as we only 
replace a single line per such class with an include. Some libraries 
might even need a declaration-only-type, other might needs an (empty) 
implementation. So, what benefit would a general type give to us?

Regards, Daniel

-- 
Daniel Frey
aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: [phone], fax: [phone]
eMail: daniel.frey_at_[hidden], web: http://www.aixigo.de