On Nov 23, 2004, at 1:00 PM, Gennadiy Rozental wrote:
"Doug Gregor" <dgregor@cs.indiana.edu> wrote in message news:0BBD3222-3D6E-11D9-9E8D-000A95B0EC64@cs.indiana.edu...
On Nov 23, 2004, at 9:37 AM, Gennadiy Rozental wrote:
"Doug Gregor" <dgregor@cs.indiana.edu> wrote in message 1. It really trivial to implement the restriction on public level:
Ok.
Does this mean that you agree that submitted library does not provide "more-capable" interface?
I do not agree and it is not relevant. If you want to talk interfaces, then talk interfaces: alternative implementations of a library are not to be the focus of a review.
The only exclusions where we may share the keywords are cases with series of related function. For example different constructors for the same class or different access methods within same class e.t.c.
All of that is escalated by what submitted solution propose in regards to type enforcing:
struct f_keywords : keywords< named_param< name_t , boost::mpl::false_ , boost::is_convertible<boost::mpl::_, std::string>
This interface is way too verbose IMO for the basic, but most widely needed, type enforcing feature.
So use a typedef or create a metafunction. The important part of a general mechanism is that it can be used for many specific cases. If you want an additional interface for a typed keyword (or other such shortcuts), ask for it.
You are asking the wrong question. The right question is "which syntax is better for users?" Step back from the implementation, the language, and the limitations of both and determine what syntax you would like to use when calling these functions. Implementation details are secondary to interface details.
This maybe the case would we were discussing named parameter feature for inclusion into language support. As it stands now, until we have template functions with variable length parameters list, the only viable option (IOW best for the user) IMO is single function interface. In theory I still would prefer single function interface:
template<typename T[]> void foo( T[] const& params ) { std::cout << params[name] << params[value]; }
Everyone would prefer a single function interface. The library authors even provide a macro that makes the implementation look like it is providing a single function interface even when it can not be implemented as such. Doug