[boost] Re: Named params lib review

From: Daniel Wallin (dalwan01_at_[hidden])
Date: 2004-11-20 20:18:14

Gennadiy Rozental wrote:
>>>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.

Just read the documentation. Or do you think enable_if<> can be replaced
by just not using templates as well?

>>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:

Positional parameters in the sense that they can be supplied either by
name or position.

>>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)

Yeah well, the reasons should be obvious for anyone that uses C++. As
Rene has already pointed out in another thread.

> 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

I would use the normal way of disabling function template overloads;
SFINAE.

> }
> 
> 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.

I'm assuming you mistyped that, in which case it's spelled:

   int v = params[a | 8];

With our library.

> 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. 

No of course it doesn't assume that. The keyword parameters is part of
the function *interface*, not the 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.

No, we are talking about the function interface, which the caller
most likely should know about.

>>I'm done in this thread now.

.. I couldn't restrain myself.

-- 
Daniel Wallin