Proto for Boost mailing list page: Re: [proto] Hold terminals by "smart" reference

Subject: Re: [proto] Hold terminals by "smart" reference
From: Eric Niebler (eric_at_[hidden])
Date: 2012-06-05 14:38:18

On 6/4/2012 5:51 PM, Mathias Gaunard wrote:
> On 04/06/2012 17:52, Eric Niebler wrote:
> 
>> I don't know what you mean by the "right type". If you want it held by
>> shared_ptr to manage lifetime, then shared_ptr is the right type, it
>> seems to me. Or use a wrapper around a shared_ptr, whichever.
> 
> I want all tree manipulation and transformation algorithms to see the
> value as if it were a T and not a shared_ptr<T> or ref_holder<T>.

OK, I see.

> shared_ptr<T> is the right type to contain the terminal in the proto
> nullary expression, but in that particular case it is not the logical
> type of the value associated to that leaf node.
> 
> I want to be able to manipulate the tree using straight Proto tools
> (otherwise I might as well not use Proto at all -- the point is to have
> a well-defined de-facto standard framework for tree manipulation).

I understand your frustration.

> Those algorithms should not need to know how the value is stored in the
> expressions. It is just noise as far as they're concerned.
> 
> Alternatively I'll need to provide substitutes for value,
> result_of::value and _value, and ban those from my code and the
> programming interface, telling developers to use mybettervalue instead
> of proto's. That saddens me a bit.

I want you to understand that I'm not just being obstructionist or
obstinate. Proto's value functions are very simple and low-level and are
called very frequently. Adding metaprogramming overhead there, as would
be necessary for adding a customization point, has the potential to slow
compiles down for everybody, as well as complicating the code, tests and
docs. There are also unanswered questions. For instance, how does
proto::matches work with these terminals? Does it match on the actual
value or the logical one? There are arguments on both sides, but one
needs to be picked. Going with the logical value will force
proto::matches to go through this customization point for every
terminal. I also am thinking about how it effects other proto features
such as: as_expr, as_child, make_expr, unpack_expr, literal+lit, fusion
integration, display_expr, fold and all the other transforms, etc. etc.
I worry that allowing the logical type of a terminal to differ from the
actual type opens a Pandora's box of tough question with no obvious
answers, and trying to add this would cause unforeseen ripple effects
through the code. It makes me very uneasy, especially considering the
workaround on your end (sorry) is very simple.

Making proto's user's happy must be balanced against feature-creep-ism,
which hurts everybody in the long run. So I'm afraid I'm still leaning
against adding this customization point. But I encourage you to file a
feature request, and if you can find a patch that doesn't negatively
effect compile times or end user-complexity and integrates cleanly with
all the other features of proto and has docs and tests, then -- and only
then --- would I add it.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com