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