Re: [boost] Re: [Review] Named parameters library

From: Joel de Guzman (joel_at_[hidden])
Date: 2004-11-18 05:34:16

Daniel Wallin wrote:
> Joel de Guzman wrote:
> 
>> 1) WRT DSL, I'm not quite sure about the syntax for
>> defaults. Example:
>>
>>     params[name | "unnamed"]
>>
>> I have a strong feeling that there's a better syntax but I am
>> not sure what it is now. I read in the thread that the syntax
>>
>>     params[name] | "unnamed"
>>
>> is not doable, but I'm not quite sure. Perhaps a clarification
>> will set me straight. Having the default in the brackets seems to
>> rather awkward. Perhaps:
>>
>>     params[name].defaults_to("unnamed")
>>
>> is better?
> 
> 
> That has exactly the same problem as having the | outside the brackets.
> The problem is that operator[] would need to return something other than
> the actual parameter reference, something that:
> 
>   1) Is convertible to the parameter type.
> 
>        We still need params[name], with no default to work.
> 
>   2) Has operator|() or defaults_to() member function.
> 
> So, we'd need a conversion operator. But if we have a conversion
> operator, we can't reliably pass the arguments to function templates
> because the type deduction will go wrong.
> 
> Does that help to clear things up?

I see. Yes, that clears things up.

>> 2) Automatic Overload Generation
>>
>> Is it not possible to elide the use of macros? Instead of:
>>
>>     template<class Params>
>>     void foo_impl(const Params&);
>>
>>     BOOST_NAMED_PARAMS_FUN(
>>         return_type, function_name
>>       , min_arity, max_arity, keywords_type
>>     );
>>
>> I'd very much prefer writing something like:
>>
>>     struct foo_
>>     {
>>         template<class Params>
>>         struct result { typedef void type; };
>>
>>         template<class Params>
>>         void eval(const Params&) const;
>>     };
>>
>>     named_interface<foo_, foo_keywords> const foo = foo_();
> 
> 
> Yes, it's doable. It's a pretty simple extension to the library.
> In fact, IIRC, one of the early design ideas was to do something like
> that. I think we didn't go down that path because someone might want ADL
> to be enabled for their functions with named params.

Yes, I'm aware of the tradeofs. The good thing is that we can have
both. There are clear advantages of functions as objects like
foo as an instantiation of named_interface<foo_, foo_keywords>.

> Maybe we could add something like this after the review.

Should be pretty straightforward.

-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net