Re: [boost] Re: Named params lib review

From: Doug Gregor (dgregor_at_[hidden])
Date: 2004-11-23 08:02:10

On Nov 23, 2004, at 1:10 AM, Gennadiy Rozental wrote:
> Problem implement function with 2 named parameter interface where 
> parameter
> 'value' is not fixed type but should comply to compile time predicate
> is_movable and parameter name is string:
>
> Submitted library solution:
> ------------------------------
>
>   keyword<struct name_t> name;
>   keyword<struct value_t> value;
>
>   struct f_keywords : keywords<
>              named_param<
>                 name_t
>               , boost::mpl::false_
>               , boost::is_convertible<boost::mpl::_, std::string>
>>
>           , named_param<
>                 value_t
>               , boost::mpl::false_
>               , is_movable<boost::mpl::_>
>>
>>
>   {};
>
>   template<typename MovableType>
>   void f_impl(std::string name, MovableType v )
>   {
>    ...
>   }
>
>   template<class Params>
>   void f(Params const& p, typename f_keywords::restrict<Params>::type =
> f_keywords())
>   // I am not actually quite sure whether above is a proper way to 
> enforce a
> restriction
>   {
>       f_impl( p[name], p[value]);
>   }

As I understand the library, the code you have written in correct.

> My suggested solution
> ------------------------------------
>
> typed_keyword<std::string,struct name_t> name;
> keyword<struct name_t> value;
>
> template<typename MovableType>
> typename boost::enable_if<is_movable<MovableType>, void>::type
> f_impl(std::string name, MovableType v )
> {
>  ...
> }
>
> template<class Params>
> void f(Params const& p)
> {
>    f_impl( p[name], p[value]);
> }
>
> ------------------------------------
>
> Now let's hear peoples subjective opinions on above choice. My 
> position that
> library should only provide support for strict type checking. Any other
> "more flexible" restrictions are user responsibility (if necessary).

There is one subtle (but important) objective difference between the 
two: with the code for the library up for review, the restrictions 
happen for the call to "f", so if one tries to pass a non-movable type 
for the value, the end result will be that "f' is removed from the 
overload set and the compiler will emit an error stating that no call 
to "f" satisfies the argument list (or another "f" will be chosen). 
With your library, the restriction occurs at the level of "f_impl", so 
passing a non-movable value to "f" will actually call that "f", but the 
instantiation will fail within "f_impl". In essence, the library under 
review provides earlier checking of the arguments than your solution, 
so that functions that may support named parameters can be eliminated 
from the overload set if they don't meet the requirements.

Granted, your typed_keyword permits earlier detection of certain typing 
errors. For instance, if I try to write "name = 5", your library will 
abort the compilation at that expression but the library under review 
will instead remove "f" from the overload set if it is called. However, 
there is a potential price to be paid for this earlier checking: the 
name "name" has now been reserved for string parameters and cannot be 
reused without introducing a new "name" keyword in some other scope 
with a different type. My (subjective) expectation is that a library 
may start by using typed keywords, but as the library evolves and more 
functions gain named parameters I'd expected those typed keywords to 
become non-typed keywords. There is no place in the BGL, for instance, 
where I would consider using a typed keyword.

Another subjective difference between the two is in the call to "f". 
The library under review supports the syntax:

    f(name = "wibble", value = int);

whereas, as I understand it, your library supports the syntax:

   f((name = "wibble", value = int));

I'm not going to weigh in on this issue.

        Doug