Boost logo

Boost :

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


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?

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

Maybe we could add something like this after the review.

-- 
Daniel Wallin

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk