[boost] Re: Named params lib review

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2004-11-20 13:28:06

> > 1. typed keywords to support strict type checking
> > 2. non-typed keywords to support template functions parameters
> > 3. optional parameters and default values ( could use with runtime if
> > without compile-time errors)
> >
> > What are the other "every feature you support" but I don't?
>
> SFINAE support,

Since you as usual did not provide an example, I may only guess that by
"SFINAE support" you mean the way to implement kind of type checking. In my
case I do not need that, cause I would be using typed keyword instead.

> positional parameters

In what sense? The way Dave described it: positional parameters first then
followed by named. In this case I believe I do support it:

template<typename Params>
foo( int a, string b, Params const& p )
...

It's not even necessary to have positional parameters in front (though I
would always do that).

> and the fatal design mistake of
> treating missing required arguments as runtime errors.

Well, I believe that compile time errors are at least an inconvenience and
at most "fatal design mistake". Here is couple reasons why (you 'forgot' to
mention any reasons for you opinion, but still)

1. Named parameter interface is assumes optional parameter in most cases.
IOW we have function with variable optional number of parameters. Fact that
one is not present is not an error, but a valid call. Now lets look how
would you implement this function:

template<Params>
foo( Params const& p  ) {

 Here you either use MP if or regular if to switch to appropriate
implementation. I find regular if  *much* more convenient and easier to
understand and implement

}

2. Default value support
If optional parameter have default value it's more obvious to write just

int v = params.has(a) ? params[s] : 8;
Then any other compile time interface you would invent.

3. Separation if implementation and invocation.
The fact that you want to detect access to missing parameter at compile time
assumes that during compiling if function invocation you have an access to
function implementation. IMO this is bad assumption in general and may not
be the case in a future (with different implementation if templates). Don't
take me wrong there some things we do want to check at compile time. But
here we talking abut function implementation details, which caller do not
need to know.

4. Non-optional parameters

The only 'bad' thing about runtime checking is that for required parameters
fact that one is missing better be detected at compile time (Note that I
don't consider runtime reports that awful either). I believe the solution
could be (if necessary) to separate notion of required and optional
parameters, by adding template parameter is_required to template keyword.

> I'm done in this thread now.

Whatever.

Good luck.

> -- 
> Daniel Wallin

Gennadiy