Re: [boost] Re: Optional, tie, and iterator_adaptor

From: Brian McNamara (lorgon_at_[hidden])
Date: 2003-08-31 14:35:21

On Sun, Aug 31, 2003 at 10:41:15AM -0700, Mat Marcus wrote:
> --On Sunday, August 31, 2003 10:29 AM -0400 Brian McNamara 
> >First off, let me say I do think this is a compelling use-case.
...
> >I missed the beginning of this thread, but I imagine the motivation
> >is to avoid having to say
> >   std::pair<Iter,Iter> p = out_edges(v,g);
> >   Iter begin = p.first;
> >   Iter end   = p.second;
> >each and every single time you call out_edges().
> 
> IIUC, you are saying that you don't find the use of tie with pairs
> very compelling. Fair enough. Of course tie is more generically useful
> with arbitrary tuples and multi-value returns. I was just trying to
> present a small familiar example of such usage.

Apologies if I was unclear; I _do_ think it's compelling.  The syntactic
convenience of being able to bind multiple names in one expression is
very nice.  (Additionally, if you're doing lots of FP stuff (like me),
it's a real pain when you have to introduce those nasty _statements_
into your code, when you'd really like to do things all in one big
_expression_.  :)  )

> In general I'm not a fan of implicit conversions or constructors.
> However one of my goals is to be able to easily/readably move code
> from using raw variables to use PossiblyUnitinitializedVariables
> instead. So..

I agree that it would be nice for PossiblyUnitinitializedVariables to be
able to be included in existing code with a minimum of fuss.  I think,
perhaps, that that goal is incompatible with avoiding implicit
conversions, though.

> ... here I like the + or something like it
> begin.reference_to_uninitialized(). That is I don't mind when users
> have to be a little more explicit in the dangerous/uncommon case. ~ is

Indeed ("make the easy/common things easy, and make the hard/uncommon 
things possible").

> also interesting, although I think that readability suffers. I'd give
> up bool conversion and operator! to avoid the need for ~ if that would
> reasonably solve the muddling issues. But perhaps there would be too
> many other problems -- I haven't explored this deeply yet.

Right; to clarify, I don't think the boolean conversion operator is
"interfering" with the implicit conversion to T.  Rather I think each is
an instance of "implicit conversion", and implicit conversions just
don't work well with templates in general, in my experience.  

I chose '+' and '~' simply because they were the two unary operators
that sprang to mind (that aren't named '*').  Personally I have no
problem with '*'; C++ has a small finite set of operators, and so you
are bound to have to overload the conceptual meanings of some operators
if you want to use them for useful syntax sugar.  The way I see it, the
optional interface using '*' is fine, and I think perhaps what people
object to is the conceptual notion of optional being 'pointer-like'.
The way I choose to see it, optional is just a special kind of
container, which happens to use '*' to get at the value in the
container, and the fact that '*' is also used to dereference pointers
is a mere coincidence of names.

But perhaps other operators (like '+' and '~') or named operations
would be more generally acceptable.  That's fine.  My main point in
joining this discussion was to emphasize that I think there ought to be
an explicit operation to 'get' the value of an optional (as well as to
get the location of raw storage to construct a new value).  What those
operations are named matters much less than simply their existence.

-- 
-Brian McNamara (lorgon_at_[hidden])