[boost] Re: [optional] update

From: Eric Friedman (ebf_at_[hidden])
Date: 2003-09-11 16:37:26

Fernando Cacciola wrote:
> Eric Friedman <ebf_at_[hidden]> wrote:
> > Really though, I'm not sure if the following would be so terrible:
> >
> >   boost::optional<A> opt(
> >       boost::in_place<A>(1234,"Hello world!")
> >     );
> >
> > After all, it's not so different from:
> >
> >   boost::optional<A> opt(
> >       A(1234,"Hello world!")
> >     );
> >
> OK, I see two choices here.
> If in_place<> uses its first template parameter to designate the target
> type, then it will be used exactly as you show above and then it could be
> adopted by variant as is.

I would prefer this to be honest...

> OTOH, it might be a bit annoying to force users to specify the target type
> all the time when it is not really necessary.

...but I can understand this perspective.

[snip]
> A shortcoming of this explicit form is that currently, the expression
> in_place(x,y,z) is an object which is untied to any particular target
> type, so I figure that it could be used as a form of currying
> that can be used to close construction expressions of all types having the
> same constructor signature. That is, it can be reused with different
> types. Anyway, this is out of the scope of the utility so we might just
> disregard it.

Right. Well I don't have any use for this, but I can see why it would be
useful. If we can keep it without significant effort, then I guess we
should.

> Alternatively, we could have two flavours of this:
>
> in_place(x,y,z) -> x,y,z are constructor parameters for any type.
> typed_in_place(T,x,y,z) -> are constructor parameters for the type T.
>
> Notice that if we want to use the same function for both cases
> there must be a way to tell whether the first parameter is the target type
> or the first contructor argument type.

I agree we need two flavors, but I don't know if they need different names.
For instance, given

  template <typename T1> void f(T1);
  template <typename U, typename T1> void f(T1);

both of the following calls are valid and unambiguous:

  f(1234);
  f<T>(1234);

I would think we could apply this idea to in_place. The only 'problem' is
that it leads to a doubling of needed overloads. So I guess we should
consider whether the 'untyped' version you've developed is worth retaining.

Eric